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Chapter  1 


Overview 


Introduction 

The  U.S.  Coast  Guard  (USCG)  is  developing  modem  automated  informa¬ 
tion  management  systems  to  further  integrate  its  supply,  maintenance,  financial, 
and  configuration  management  functions  as  part  of  its  Systems  to  Automate  and 
Integrate  Logistics  (SAIL)  project.  The  Fleet  Logistics  System  (FLS),  a  key  com¬ 
ponent  of  SAIL,  has  been  initiated  to  "develop  an  integrated  system  to  support 
fleet  logistics."1  The  Coast  Guard  Logistics  Management  Division  (G-ELM), 
Office  of  Engineering,  Logistics  and  Development,  has  designated  the  Materiel 
Management  System  (MMS)  as  the  future  unit-level  Coast  Guard  requisitioning 
system,  replacing  the  Automated  Requisition  Management  System  (ARMS).  The 
FLS  conceptual  architecture  report  defines  MMS  as  a  system  that 

. . .  supports  the  generation  of  MTLSTRTP  transactions  by  USCG,  forwards  them  to 
DAAS,  and  keeps  records  of  these  transactions  and  those  sent  from  DAAS  to  USCG.  It 
tracks  parts  starting  from  MTLSTRIP  shipment  transactions  through  delivery.  It  will 
also  support  the  staging  of  materiels  for  scheduled  intermediate  and  depot  level  main¬ 
tenance  periods.  In  addition  this  application  captures  information  on  commercial  pur¬ 
chases.  This  information  capture  provides  the  critical  data  needed  by  the  USCG  to 
evaluate  commercial  supply  and  federal  supply  system  performance.13 

From  that  definition,  we  envisage  MMS  as  the  unit-level  means  for  creating 
requisitions  from  requirements  submitted  by  other  unit-level  applications;  trans¬ 
mitting  requisitions  to  the  source  of  supply  and  the  financial  system;  and 
transferring  information  on  requisition  and  commercial  procurement  to  the  data 
collection  system.  It  will  receive  supply  status  transactions  from  the  source  of 
supply  and  distribute  them  to  the  unit,  financial  system,  and  data  collection  sys¬ 
tem. 


Previous  Materiel  Management  System  Studies 

In  June  1991,  the  Coast  Guard  Electronics  Engineering  Center  completed  the 
business  area  analysis  (BAA)  defining  the  functional  requirements  for  MMS.  In 
that  analysis,  it  proposed  that  an  "MMS  Central"  be  developed  as  an  inter- 


1  Fleet  Logistics  System  (FLS)  Conceptual  Architecture  Report  (CAR)  (draft)  Volpe 
National  Transportation  Systems  Center,  4  December  1992. 

2  Ibid.,  Appendix  A,  p.  22. 

3MILSTRIP  =  Military  Standard  Requisitioning  and  Issue  Procedures;  DAAS  = 
Defense  Automatic  Addressing  System. 
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mediate  stop  between  the  unit  and  DAAS.4  All  requisitions  from,  and  status  to, 
the  units  would  pass  through  MMS  Central.  The  MMS  Central  computer  would 
take  on  the  additional  task  of  collecting  requisition-related  information  for  man¬ 
agement  retrieval 

Unlike  ARMS,  the  current  requisitioning  system,  the  proposed  MMS  Cen¬ 
tral  computer  will  not  validate  the  requisition's  financial  information  or  transmit 
obligation  accounting  data  to  the  Department  of  Transportation  (DOT)  finance 
center  in  the  Departmental  Accounting  and  Financial  Information  System 
(DAFIS)  format  The  BAA  proposes  that  each  requisition  have  a  "CG"  fund  code 
to  identify  that  the  bills  should  be  sent  to  the  Coast  Guard  Finance  Center 
(FINCEN).  Financial  obligation  data  will  be  transmitted  to  the  FINCEN  by  the 
unit  through  the  Large  Unit  Financial  System  (LUFS). 

Review  of  the  BAA  proposal  raised  the  following  issues: 

♦  The  BAA  proposal  for  transmitting  financial  information  was  incomplete.  It 
made  no  accommodation  for  units  without  LUFS  to  send  requisition  finan¬ 
cial  obligation  information  to  the  FINCEN.  It  did  not  address  how  the  obli¬ 
gation  would  be  input  to  DAFIS  or  how  the  FINCEN  would  identify  the 
proper  line  of  accounting  to  charge  when  it  receives  a  bill  for  die  requisi¬ 
tioned  item. 

♦  The  BAA  assumed  that  the  Coast  Guard  would  implement  Defense  Logis¬ 
tics  Management  Systems  (DLMS)  Version  1.1  transaction  formats.  Subse¬ 
quently,  the  Coast  Guard  decided  to  implement  an  improved  version, 
DLMS  Version  2.0,  currently  being  developed. 

♦  The  BAA  does  not  address  the  transmission  and  collection  of  commercial 
purchasing  information. 

In  its  efforts  to  support  SAIL,  the  Volpe  National  Transportation  System 
Center  (VNTSQ  tasked  the  Logistics  Management  Institute  (LMI)  to  study  and 
redefine  die  functional  business  practices  for  the  Coast  Guard's  unit-level  requi¬ 
sitioning  process. 


Area  of  Analysis 

This  study  examines  the  unit-level  materiel  procurement  processes  for  req¬ 
uisitioning  an  item  from  the  Federal  Supply  System  and  purchasing  an  item 
from  a  commercial  vendor.  Our  analysis  includes  the  process  involved  in  creat¬ 
ing  and  transmitting  unit-level  materiel  procurement  transactions  and 
requisition-related  information  and  the  data  requirements  of  various  entities  af¬ 
fected  by  the  requisitioning  process.  Those  include  DAFIS,  the  FINCEN,  and 
supply  activities. 


4  MMS  Central  describes  a  central  processing  point  to  which  all  transactions  are  sent 
to  be  validated  and  stored  before  they  are  forwarded  to  the  source  of  supply. 
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Major  Issues 


In  our  analysis  of  the  requirements  for  the  MMS,  we  focused  on  the  follow¬ 
ing  four  major  issues: 

♦  The  method  of  transmitting  and  validating  requisition-related  financial 
information 

♦  The  process  for  collecting  and  providing  access  to  requisition  and  commer¬ 
cial  purchasing  data 

♦  The  communications  methods  used  to  transmit  requisitions  from  all  Coast 
Guard  units 

♦  The  effect  of  DLMS  Version  2.0  on  the  implementation  of  MMS. 

Insofar  as  the  first  issue  is  concerned,  key  questions  may  be  divided  into  two 
general  categories  —  financial  data-editing  check  and  financial  data  transmission 
in  DAFIS  format  The  first  set  of  questions  relates  to  the  nature  of  the  financial 
data-editing  check  and  its  location  in  the  process.  Should  the  editing  check  be 
done  at  the  unit  level  or  at  a  central  location?  If  it  is  done  at  the  unit  level,  how 
should  it  be  performed?  The  second  set  of  key  questions  entails  deciding  the 
point  in  the  process  at  which  the  DAFIS  transaction  should  be  created.  Should, 
for  example,  the  entity  creating  the  transaction  submit  a  DAFIS-formatted 
transaction?  Or  should  MMS  provide  a  translator  on  the  front  end  of  DAFIS  to 
convert  standard  transactions  into  DAFIS  format? 

The  key  question  for  the  second  issue  is  whether  the  Coast  Guard  should 
create  a  customized  data-collection  system  or  use  an  existing  DoD-sponsored 
data  base  (such  as,  perhaps,  the  Logistics  Information  Processing  System). 

The  third  issue  deals  with  the  system  that  transmits  MMS  transactions 
among  the  unit,  supply  activities,  and  financial  system.  The  issue  entails  the 
need  to  create  a  transaction  transmission  system  with  a  communications  gateway 
flexible  enough  to  accommodate  all  MMS  users.  The  key  questions  are:  What 
type  of  facilities  are  necessary  to  allow  both  shore  and  afloat  units  to  have  access 
to  MMS?  Can  the  operating  instructions  to  DAAS  be  changed  to  allow  the 
current  communication  methods  (telephone  and  messages)  to  be  used?  Does  a 
system  such  as  SALTS5  need  to  be  created  or  can  SALTS  satisfy  Coast  Guard 
requirements? 


5  Streamlined  Automated  Logistics  Transmission  System  (SALTS)  is  a  communica¬ 
tions  network  established  by  the  Navy  to  permit  afloat  and  shore  units  to  pass  logistics 
information  quickly  and  easily  via  satellite,  telephone  landline,  cellular  telephone  sys¬ 
tems,  and  portable  field  units.  SALTS  Central  is  located  at  the  Aviation  Supply  Office, 
Philadelphia,  Pa. 
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The  last  issue  relates  to  the  implementation  of  DLMS  Version  2.0  conven¬ 
tions.  The  key  questions  are  when  will  those  conventions  be  available,  what  are 
the  risks  of  converting  to  DLMS  Version  2.0,  and  how  can  the  risks  be  mitigated? 


Study  Objectives 

Our  primary  objective  is  to  recommend  a  redesign  of  the  business  practices 
associated  with  establishing  a  unit-level  requisition  submission  system  and  the 
data-collection  and  -tracking  system  for  requisitioning  and  commercial  purchas¬ 
ing  information.  In  this  study,  we  determine  the  business  practices  for  a  requisi¬ 
tioning  system  on  the  basis  of  the  current  functionality  of  ARMS  and  the  FLS 
conceptual  architecture  report  definition  of  MMS. 

We  also  address  the  impact  of  implementing  DLMS  Version  2.0  on  MMS, 
and  we  outline  the  increased  capabilities  provided  by  DLMS  Version  2.0  transac¬ 
tion  formats.  We  also  assess  the  risks  and  remedies  available  to  the  Coast  Guard 
in  converting  to  DLMS  Version  2.0  format. 


Summary  of  Recommendations 

From  our  analysis  of  the  issues  and  requirements  of  MMS,  we  recommend 
that  the  Coast  Guard  take  the  following  actions: 

♦  Perform  requisition-related  financial  data  edit  checking  at  the  unit  level 

♦  Eliminate  the  operating  facility  (OPFAC)/fund  code  table  and  replace  it 
with  the  standardized  fund  code  we  propose 

♦  Develop  and  maintain  a  translator  to  convert  Defense  Logistics  Standard 
System  (DLSS)  transactions  into  DAFIS-formatted  transactions 

♦  Locate  the  financial  translator  at  the  FINCEN 

♦  Establish  a  Coast  Guard  logistics  intelligence  file  (CGLIF)  to  capture  all 
requisition  and  commercial  purchase  information 

♦  Design  the  CGLIF  to  recognize  the  data  requirements  of  the  parts  tracking 
system 

♦  Monitor  the  development  of  both  MMS  and  the  parts-tracking  system  to 
ensure  functional  consistency  and  prevent  duplication  of  process 


6  We  do  not  recommend  the  establishment  of  an  MMS  Central.  While  our  proposed 
organization  includes  organizational  entities  that  perform  each  of  the  functions  of  an 
MMS  Central,  we  do  not  believe  that  all  of  those  functions  have  to  be  performed  at  a  cen¬ 
tral  site. 


1-4 


♦  Establish  a  communications  gateway  that  can  accommodate  both  requisi¬ 
tion  and  commercial  purchase  transactions 

♦  Instruct  DAAS  to  route  a  copy  of  all  Coast  Guard  message  and  Defense 
Automated  Message  Exchange  System  (DAMES)  requisitions  through 
ARMS  until  a  communications  gateway  is  established 

♦  Provide  the  capability  for  MMS  to  automatically  select  either  DLSS  or 
DLMS  formats 

♦  Review  DLMS  enhancements  and  determine  what  enhanced  data  capabili¬ 
ties  apply  to  Coast  Guard  logistics  transactions. 


Report  Organization 

In  the  next  three  chapters,  we  address  the  background  and  issues  and 
answer  the  questions  that  we  identify  above.  In  Chapter  2,  we  outline  the  requi¬ 
sitioning  systems  that  MMS  will  replace  and  we  present  general  descriptive 
information  on  DLMS.  In  Chapter  3,  we  deal  with  the  four  major  issues  of  the 
redesigned  MMS  business  practices:  financial  requirements,  data  collection 
requirements,  communications  requirements,  and  implementing  DLMS.  We  also 
discuss  some  interim  process  improvements  in  that  chapter.  In  Chapter  4,  we 
present  the  recommended  MMS  processes  and  organizational  entities. 
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Chapter  2 

Background 


Current  Requisitioning  Systems 

To  enter  a  requisition  into  the  Federal  Supply  System,  a  Coast  Guard  unit 
can  either  use  ARMS,  or  can  send  the  requisition  directly  to  the  DAAS  by  using 
either  DAMES  or  an  Automated  Digital  Network  (AUTODIN)  message.  ARMS, 
developed  by  the  Coast  Guard,  requires  the  requisitioner  to  have  access  to  a 
Coast  Guard  standard  workstation,  a  modem,  and  a  commercial  telephone  line. 
Both  methods  send  requisitions  in  DLSS  format. 


Automated  Requisition  Management  System  Requisitions 

The  ARMS  requisitioning  system  is  made  up  of  two  systems.  Interactive 
ARMS  and  Batch  ARMS.  Interactive  ARMS  was  developed  in  1979  as  the  pri¬ 
mary  means  for  sending  DLSS  requisitions  from  the  Coast  Guard  standard 
workstations.  Batch  ARMS,  which  creates  a  batch  of  requisitions  and  sends  them 
to  the  Transportation  Computer  Center  (TCQ  Amdahl  computer1  in  one  trans¬ 
mission,  was  developed  and  made  available  throughout  the  Coast  Guard  in  1988. 
In  1990,  Batch  ARMS  was  incorporated  as  a  subsystem  of  the  LUFS.  This  change 
allowed  requisitioning  units  to  update  their  financial  ledgers  automatically  upon 
requisition  transmission. 

The  use  of  ARMS  is  constrained  by  the  availability  of  telephone  lines  or  a 
Coast  Guard  Data  Network  connection.  Afloat  units  at  sea  do  not  have  access  to 
it;  when  in  port,  those  units  often  do  not  have  enough  commercial  telephone 
landlines  to  devote  one  to  sending  ARMS  requisitions. 

Currently,  ARMS  sends  DLSS  requisitions  to  DAAS  over  the  TCC  Amdahl 
computer  (Figure  2-1).  The  computer  matches  the  requisition's  fund  code  against 
a  fund  code  table  to  verify  that  it  is  authorized.  If  the  OPFAC2/ fund  code  combi¬ 
nation  is  invalid,  the  requisition  is  returned  to  the  requisitioner  for  correction. 
Requisitions  that  pass  this  edit  check  are  sent  to  DAAS,  which  then  forwards  the 
requisition  to  the  source  of  supply.  At  the  same  time,  the  TCC  Amdahl  computer 
matches  the  OPFAC/  fund  code  combination  with  DAFIS-formatted 


1  That  computer  is  located  at  DOT  Headquarters.  The  Coast  Guard  leases  space  on 
that  computer  to  run  the  ARMS  application. 

2  The  OPFAC  is  a  five-digit  identification  number  that  has  been  assigned  to  each  op¬ 
erating  unit  in  the  Coast  Guard.  This  number  is  used  for  fiscal  and  accounting  purposes 
to  collect  the  cost  of  operating  the  unit 
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(320  characters),  full-line,  accounting  data.  The  accounting  data  are  forwarded  to 
the  DAFIS  computer  center  to  create  a  financial  obligation. 


Figure  2-1. 

ARMS  Requisition  Flow 


Requisitioned  using  the  Interactive  ARMS  method  create  requisitions  inter¬ 
actively  while  logged  on  to  the  TCC  Amdahl  computer.  The  Interactive  ARMS 
program  performs  all  edit  checks  to  ensure  requisition  data,  including  the  fund 
code,  are  correct  before  the  requisition  is  accepted.  Only  after  a  requisition  is 
accepted,  can  the  unit  create  another  requisition.  Although  reliable,  interactive 
ARMS  can  be  time  consuming  because  it  creates  requisitions  one  at  a  time.  Units 
that  send  many  requisitions  using  Interactive  ARMS  can  tie  up  telephone  lines 
for  a  long  time  and  incur  high  long-distance  telephone  charges. 

Batch  ARMS  creates  a  batch  of  requisitions  on  the  Coast  Guard  workstation 
before  logging  on  to  the  TCC  Amdahl  computer.  The  unit  then  sends  the  batch  of 
requisitions  through  remote  job  entry  (RJE)  software.  After  the  requisitions  are 
received,  ARMS  validates  the  requisitions.  The  valid  requisitions  are  accepted 
and  forwarded  to  DAAS  and  the  DAFIS  computer  center,  while  the  invalid 
requisitions  are  returned  to  the  unit  for  correction.  Batch  ARMS  is  faster  and 
places  less  demand  on  telephone  resources  than  Interactive  ARMS.  Despite  its 
advantages,  however,  many  potential  users  have  found  the  RJE  communication 
link  with  the  TCC  Amdahl  computer  difficult  to  establish.  For  that  reason,  many 
potential  users  do  not  use  Batch  ARMS.  The  FINCEN  and  G-ELM  are  currently 
testing  an  asynchronous  tile  transfer  process  to  improve  the  communication  link 
for  Batch  ARMS. 

The  TCC  Amdahl  computer  transmits  requisition  status  and  changes 
received  from  DAAS  to  the  financial  system  and  the  requisitioner.  In  addition  to 
forwarding  status  information  to  the  requisitioning  unit,  the  TCC  Amdahl  com¬ 
puter  translates  status  transactions  that  have  financial  application  —  such  as 
price  changes,  quantity  changes,  or  cancellations  —  into  DAFIS  transactions  and 
forwards  them  to  the  DAFIS  computer  center. 
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Additional  Requisitioning  Methods 

Coast  Guard  units  that  choose  not  to  use  ARMS  to  send  DLSS  requisitions 
have  two  additional  methods:  message  and  DAMES.  As  Figure  2-2  shows,  both 
methods  bypass  ARMS  and  send  requisitions  directly  to  DAAS.3  Message  requi¬ 
sitions  are  used  mostly  by  afloat  units,  which  do  not  have  commercial  telephone 
service.  DAMES,  which  is  used  by  a  limited  number  of  Coast  Guard 
requisitioners,  transmits  requisitions  to  DAAS  over  commercial  telephone  lines. 
It  is  preferred  to  ARMS  because  its  requisitions  are  received  by  the  source  of  sup¬ 
ply  faster,  and  communication  software  presents  fewer  problems  than  the  RJE 
software  used  by  ARMS. 


Figure  2-2. 

Nott-ARMS  Requisition  Flow 


The  processing  of  non- ARMS  requisitions  differs  from  that  of  ARMS  requisi¬ 
tions  in  that  both  message  and  DAMES  requisitioning  processes  bypass  the  TCC 
Amdahl  computer  and  send  requisitions  directly  to  DAAS.  Thus,  non-ARMS 
requisitions  are  processed  differently  than  ARMS  requisitions.  One  functional 
difference  is  that  DAFIS  accounting  data  is  not  automatically  sent  to  the  DAFIS 
computer  center  to  create  an  obligation.  Another,  is  that  fund  codes  on  non- 
ARMS  requisitions  are  not  validated  before  the  requisition  is  sent  to  the  source  of 
supply. 

The  requisitioning  unit  must  send  a  document  identifier  code  (DIQ  ZOA 
transaction  that  mirrors  the  requisition  to  the  TCC  Amdahl  computer  to  initiate 
an  obligation.  The  TCC  Amdahl  computer  will  match  the  OPF AC/fund  code 
combination  on  the  DIC  ZOA  with  a  line  of  accounting  data  and  submit  a  DAFIS 
transaction  to  create  an  obligation.  If  the  requisitioning  unit  does  not  send  a  DIC 
ZOA,  an  obligation  will  be  created  when  requisition  status  is  received  at  DAFIS 
from  the  TCC  Amdahl  computer. 


3  At  the  time  of  this  report,  SALTS  was  being  tested  on  the  USCG  cutters  Jarvis,  Polar 
Star,  and  Polar  Sea.  We  discuss  SALTS  in  more  detail  later  in  this  report. 
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Since  the  DAAS  edit  check  does  not  validate  fund  codes,  the  requisitioning 
unit  may  send  a  message  or  DAMES  requisition  with  an  improper  fund  code  and 
the  source  of  supply  will  process  the  requisition,  issue  materiel  requested,  and 
bill  the  FINCEN  for  the  requisitioned  materiel.  When  the  bill  for  the  materiel  is 
submitted  with  an  improper  fund  cited,  the  FINCEN  is  required  to  manually  re¬ 
search  the  transaction  to  determine  what  account  to  charge  because  an  obligation 
has  not  been  created. 


Modernization  of  the  Defense  Logistics 
Standard  System 

The  Coast  Guard  obtains  much  of  its  reparable  and  consumable  materiel 
support  requirements  from  the  Military  Services  and  other  Federal  agencies.  The 
current  Coast  Guard  requisition  system  conducts  its  logistics  communications 
(both  intra-Coast  Guard  and  interagency)  in  conformance  with  long-established 
Department  of  Defense  (DoD)  procedures.  In  the  remainder  of  this  chapter,  we 
review  these  DoD  procedures  and  describe  DoD  plans  to  modernize  them.  The 
Coast  Guard  must  evaluate  whether  to  incorporate  those  changes  into  the  MMS 
and  the  supply  center  modernization,  and  if  they  are  to  be  added,  how  and  when 
to  do  so. 


Background  to  the  Defense  Logistics  Standard  System 

The  DoD  uses  tile  "single-item  manager"  concept  to  manage  its  materiel. 
Under  that  concept,  management  of  each  item  used  by  DoD  is  assigned  to  the 
Defense  Logistics  Agency  (DLA),  a  Military  Service,  the  General  Services  Ad¬ 
ministration,  or  some  other  agency.  This  centralized  management  of  materiel  re¬ 
quires  a  great  deal  of  communication  between  item  managers  and  requisitioned. 

To  facilitate  those  communications,  DoD  established  the  Military  Standard 
Requisitioning  and  Issue  Procedures  (MILSTRIP)  in  July  1962.  MILSTRIP  defines 
standard  formats  and  procedures  for  requisitioning  materiel  and  designates  the 
medium  for  transmitting  the  data  that  will  be  entered  into  computer  systems. 

Because  of  the  success  of  MILSTRIP,  DoD  developed  additional  systems  to 
define  procedures  in  the  following  functions: 

♦  Inter-Service  billing  —  Military  Standard  Billing  and  Fund  Transfer  Proce¬ 
dures  (MILSBILLS) 

♦  Inventory  management  —  Military  Standard  Transaction  Reporting  and 
Accounting  Procedures  (MILSTRAP) 

♦  Supply  system  performance  evaluation  and  management  reporting  —  Mili¬ 
tary  Standard  Supply  and  Transportation  Evaluation  Procedures  (MILSTEP) 
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♦  Discrepant  materiel  —  Report  of  Discrepancy  (ROD)  which  is  renamed  Sup¬ 
ply  Discrepancy  Report  (SDR) 

♦  Transportation  —  Military  Standard  Transportation  and  Movement  Proce¬ 
dures  (MUST  AMP) 

♦  Contract  management  —  Military  Standard  Contract  Administration  Proce¬ 
dures  (MILSCAP). 

These  procedures  are  collectively  known  as  the  Defense  Logistics  Standard 
Systems  (DLSS).  Figure  2-3  illustrates  the  many  data  exchanges  that  occur  within 
the  DLSS. 
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Figure  2-3. 

Overview  of  DLSS  Environment 


New  User  Requirements 

The  concepts  introduced  by  the  DLSS  in  1962  put  DoD  at  the  leading  edge  of 
logistics  technology.  However,  today,  the  DLSS  and  many  of  their  supporting 
automated  data  processing  (ADP)  systems  remain  about  as  they  were  at  their  in¬ 
ception.  In  those  intervening  30  years,  computer  and  telecommunications  tech¬ 
nology  grew  enormously,  and  improvements  in  logistics  management 
techniques  paralleled  that  growth.  That  revolutionary  growth  spurred  increased 
demands  for  logistics  data  that  the  DLSS  cannot  readily  support.  These  demands 
come  from  the  spectrum  of  participants  such  as  unit  supply  officers,  high-level 
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civilian  and  military  managers,  auditors,  and  Congress.  These  demands  include 
the  following: 

♦  Better  inventory  management  to  reduce  system  costs 

♦  On-line  access  to  the  logistics  status  of  materiel  and  of  specific  transactions 

♦  Production,  stockage,  and  in-transit  visibility  information  on  key  supply 
items 

♦  New  methods  of  controlling  supply  items  (such  as  parts  pooling  version 
to  most-critical  need,  or  associated  weapon  system). 


Development  of  the  Defense  Logistics  Management  System 

The  DoD  responded  to  the  need  to  meet  user  requirements  and  capitalize  on 
new  technologies  by  initiating  the  Modernization  of  the  Defense  Logistics  Stan¬ 
dard  Systems  (MODELS)  program.  A  DoD  memorandum  defines  MODELS  as 
"not  merely  an  update  of  assorted  procedures  but  a  fundamental  redesign  of  the 
way  DLSS  functions  are  performed."  Subsequently,  to  reflect  the  fundamental 
change  planned  for  the  system,  DoD  assigned  a  new  name  to  the  DLSS  process, 
the  Defense  Logistics  Management  System  (DLMS). 

A  key  accomplishment  of  the  program  is  replacing  the  DLSS  fixed-length 
formats  with  a  variable-length  format  The  American  National  Standards  Insti¬ 
tute's  (ANSI)  Accredited  Standards  Committee  (ASC)  X12  standards  for  elec¬ 
tronic  data  interchange  (EDI)4  offered  a  broad  base  of  business  transactions  to 
support  MODELS.  More  than  425  DLSS  fixed-length  formats  were  consolidated 
into  approximately  25  X12  transactions. 

The  conversion  from  fixed-length  format  to  the  EDI  format  did  not  consist 
solely  of  mapping  the  old  transactions  into  new  ones.  More  than  200  requests  for 
additional  data  and  new  capabilities  were  submitted  and  reviewed  by  the 
Defense  Logistics  Management  Standards  Office  (DLMSO)  and  the  Services  and 
agencies  in  DoD.  More  than  100  of  these  have  been  incorporated  into  DLMS  Ver¬ 
sion  2.0.  The  Coast  Guard  has  fully  participated  in  the  development  and  review 
of  the  DLMS. 


4  EDI  is  the  computer-to-computer  exchange  of  business  documents  electronically 
between  organizations  using  a  standard  format  Its  use  eliminates  delays  and  expenses 
associated  with  manual  handling  of  paper  forms  and  also  reduces  costs  and  improves 
organizational  efficiency.  It  has  been  used  widely  within  industry  for  a  number  of  years. 
The  Federal  Government  including  the  Coast  Guard  FINCEN,  is  making  increasing  use 
of  it.  The  DLSS  are  in  fact  an  early  version  of  EDI  that  use  DoD  proprietary  standards 
rather  than  the  commercial  ASC  X12  standards. 
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Most  of  the  DLMS-related  transaction  sets  were  published  as  ASC  X12  EDI 
standards,  Version  3,  Release  3,  in  December  1992.5  Incorporation  of  the  balance 
of  DoD's  DLMS  requirements  into  the  ASC  X12  standards  should  be  published 
in  the  December  1993  release. 


Development  of  DoD  Manuals  and  Implementation  Conventions 

The  establishment  of  the  initial  DLMS  transaction  sets  within  the  ASC  X12 
standards  represents  just  the  first  step  in  the  MODELS  development  effort  To 
ensure  effect /e  use  of  the  new  transaction  sets,  DLMSO  has  taken  the  lead  to  do 
the  following: 

♦  Rewrite  the  several  DLSS  manuals  into  a  single  DLMS  manual  to  reflect  the 
new  transactions  and  to  establish  policy  on  new  data  elements  and  revised 
procedures 

♦  Develop  implementation  conventions  describing  the  specific  data  elements 
and  codes  that  will  be  used  for  conveying  DLMS  data. 

Currently,  DLMSO  is  developing  the  draft  DLMS  manual  that  includes  im¬ 
plementation  conventions.  The  manual  with  implementation  conventions  is  due 
to  the  Joint  Logistics  Systems  Center  and  the  Defense  Distribution  System  Cen¬ 
ter  by  June  1994.  The  draft  implementation  convention  for  the  requisition  is  cur¬ 
rently  available,  and  most  of  the  remaining  MMS-related  transaction  sets  should 
be  available  to  the  Coast  Guard  by  the  fall  of  1993. 


Integration  with  Other  Initiatives 

The  DLMS  cannot  be  viewed  in  isolation.  It  is  an  integral  part  of  DoD's 
overall  effort  to  utilize  standard  approaches  and  to  improve  performance  while 
reducing  costs.  Other  initiatives  include  the  following: 

♦  Federal  Information  Processing  Standard  (FIPS)  161.  FIPS  161  defines  tine 
ASC  X12  as  one  of  the  two  approved  standards  for  Federal  use  of  EDI. 

♦  Corporate  Information  Management  (CIM).  The  CIM  initiative  is  intended  to 
dramatically  reduce  the  number  of  redundant  ADP  systems  and  replace 
them  with  standard  DoD  systems.  CIM  system  development  for  the  mate¬ 
riel  management  functional  area  is  being  directed  by  the  Joint  Logistics  Sys¬ 
tems  Center  [for  inventory  control  point  (ICP)  systems]  and  the  Defense 
Distribution  System  Center  (for  depot  systems). 


5  Accredited  Standards  Committee.  Electronic  Data  Interchange  X12  Standards,  Draft 
Version  3,  Release  3,  Volume  1.  Data  Interchange  Standards  Association,  Inc.,  December, 
1992. 
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♦  Computer-aided  Acquisition  and  Logistics  System  (CALS).  CALS  will  be  used  to 
exchange  technical  and  engineering  data  among  Government  and  industry 
computers.  CALS  will  use  EDI  transactions  as  the  basis  for  exchanging  data. 

♦  Defense  Management  Report  Decision  (DMRD)  941.  The  DMRD  and  other  DoD 
policy  directs  the  Defense  Components  to  implement  EDI  and  specifically 
cites  20  DoD  forms  that  are  to  serve  as  the  initial  efforts  to  replace  paper 
forms  with  electronic  transactions.  The  DMRD  provides  the  Components 
with  investment  dollars  and  budget  reductions  based  on  estimated  savings. 

The  forms  specified  in  DMRD  941  are  used  in  such  functional  areas  as  sup¬ 
ply,  maintenance,  transportation,  and  procurement  The  procurement  area  uses 
both  the  highest  volume  of  forms  and  consequently  offers  the  greatest  potential 
savings.  All  of  the  Services  and  DLA  have  initiated  projects  to  use  ASC  X12  stan¬ 
dards  to  exchange  procurement,  payment,  and  transportation  data  with  indus¬ 
try.  These  projects  are  being  implemented  at  both  the  wholesale  (ICP)  and  retail 
levels. 

The  Defense  Information  Systems  Agency  (DISA)  plans  to  establish  contracts 
with  commercial  suppliers  of  information  services  [typically  called  value-added 
networks  (VANs)].  DoD  activities  would  forward  EDI  transactions  to  one  of  four 
DoD  distribution  points6  that  in  turn  pass  the  transactions  to  the  VANs.  For  retail 
procurement,  the  VANs  will  generally  place  solicitations  on  a  bulletin  board 
where  they  can  be  reviewed  by  a  large  number  of  vendors  who  can  respond  with 
electronic  bids.  Early  experiments,  including  the  Navy's  electronically  assisted 
solicitation  exchange  (EASE)  and  the  Air  Force's  Government  acquisition 
through  electronic  commerce  (GATEQ,  have  shown  that  substantial  cost  savings 
can  be  obtained. 

As  Figure  2-3  shows,  the  flow  of  data  among  DoD  Components  using  DLSS 
(DLMS  in  the  future)  and  the  exchanges  of  logistics  data  between  DoD  Compo¬ 
nents  and  industry.  These  paper  exchanges  will  be  replaced  by  EDI.  Successful 
implementation  of  the  DLMS  and  EDI  exchanges  with  industry  will  unify  the 
format  of  both  internal  and  external  DoD  logistics  data  exchanges  under  the 
ASC  X12  EDI  standards. 


4  Defense  Automatic  Addressing  System  Center  and  the  Aviation  Supply  Office  will 
be  the  first  two  distribution  points. 
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Chapter  3 


Major  Materiel  Management  System 
Requirements,  Issues,  and 
Recommendations 


Introduction 

The  future  Coast  Guard  requisitioning  system,  MMS,  will  collect  historical 
and  tracking  information  on  all  requisitions  and  commercial  procurements  and, 
in  addition,  will  provide  all  the  functions  currently  provided  by  ARMS.  It  will 
create  transactions,  transmit  and  receive  information,  and  store  information  for 
requisitioning  and  commercial  procurements.  Coast  Guard  units  will  use  MMS 
to  create  DLSS/DLMS  requisitions.  It  will  transmit  requisitions  to  DAAS,  finan¬ 
cial  obligation  information  to  the  financial  system,  requisition  status  from  DAAS 
to  Coast  Guard  units  and  the  financial  system,  requisition  and  commercial  pur¬ 
chase  information  to  historical  and  tracking  files,  and  shipping  and  staging  infor¬ 
mation  to  central  tracking  files.  It  will  maintain  a  data  repository  of  active  and 
historical  information  and  will  answer  users'  queries  on  shipment  tracking 
information,  requisition  status,  and  historical  requisition  and  commercial  pro¬ 
curement  information.1 

In  brief,  MMS  will  do  the  following: 

♦  Transmit  valid  financial  information  to  the  financial  system 

♦  Collect  requisition  and  commercial  procurement  data 

♦  Transmit  requisitions  from  all  Coast  Guard  units  in  all  foreseeable  situations 

♦  Be  DLMS  Version  2.0  capable. 

Those  four  activities  are  discussed  in  the  remainder  of  this  chapter.  We  dis¬ 
cuss  our  findings,  conclusions,  and  recommendations  for  each  activity. 


'Fleet  Logistics  System  (FLS)  Conceptual  Architecture  Report  (CAR)  (draft),  Volpe 
National  Transportation  Systems  Center,  4  December  1992. 
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Financial  Requirements 


As  the  replacement  system  for  ARMS,  MMS  must  be  capable  of  transmitting 
valid  requisition-related  financial  information.  The  information  received  from 
MMS  must  be  accurate  and  in  a  format  understandable  to  the  financial  system. 

The  financial  system  requires  each  requisition  created  by  a  Coast  Guard  unit 
to  identify  the  account,  represented  by  a  nine-data  -element  line  of  accounting 
data,  that  will  pay  for  the  requisitioned  item  and  how  much  the  requisitioned 
item  will  cost  The  line-of-accounting  data  consists  of  the  following  nine  data  ele¬ 
ments: 

♦  Agency 

♦  Region  code 

♦  Appropriation  code 

♦  Appropriation  limitation  code 

♦  Allotment  fund  code 

♦  Program  element 

♦  Cost  center 

♦  Object  class 

♦  System  data. 

The  current  Coast  Guard  requisitioning  process  uses  a  two-digit  fund  code2 
in  combination  with  the  requisition's  OPFAC3  to  identify  the  appropriate 
accounting  data.  The  requisition's  fund  code  and  OPFAC  combination  tells  the 
ARMS  computer  at  TCC  which  line  of  accounting  data  to  utilize  and  transmit  to 
the  financial  system. 

Each  unit  is  assigned  several  lines  of  accounting  data  to  charge  goods  and 
services.  For  a  typical  unit,  the  object  class4  used  to  designate  the  obligation  clas¬ 
sification  for  the  requisitioned  item  is  the  only  data  element  that  is  different 
between  lines  of  accounting  data. 

Because  neither  the  OPFAC  nor  the  fund  code  by  itself  provides  sufficient 
information  for  the  FINCEN  to  identify  the  correct  line  of  accounting  data  to 

2  A  fund  code  is  a  two-character  alphanumeric  code  (created  by  the  FINCEN)  that  in 
combination  with  the  requisition's  OPFAC  identifies  a  line  of  accounting  data. 

3  The  OPFAC  is  identified  in  the  requisition  number  field  of  each  requisition. 

4  The  object  class  is  a  four-digit  code  classifying  the  nature  of  costs  incurred  for  obli¬ 
gations  and  expenditures.  Object  classes  identify  costs  such  as  services,  travel,  supplies, 
and  materiels. 
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charge,  the  FINCEN  has  a  fund  code  table  that  links  the  requisition's  OPFAC  and 
the  fund  code  to  a  line  of  accounting  data.  The  OPFAC/ fund  code  table  is  used 
by  the  ARMS  computer  to  identify  the  line  of  accounting  data  to  send  to  the 
DAFIS  computer  center  to  create  an  obligation  and  by  the  FINCEN  to  charge  a 
line  of  accounting  data  when  a  bill  is  received  for  a  DLSS  requisition  or  an 
invoice  is  received  for  a  commercial  procurement 

The  current  OPF AC/fund  code  table  has  at  least  one  OPFAC/ fund  code 
combination  for  each  line  of  accounting  data.  An  OPFAC/  fund  code  combina¬ 
tion  is  assigned  every  time  a  new  line  of  accounting  data  is  established  or  at  the 
beginning  of  a  new  fiscal  year.  Additionally,  lines  of  accounting  data  that  can  be 
charged  by  more  than  one  requisitioner  are  assigned  multiple  OPFAC/ fund 
code  combinations.  For  example,  when  a  requisitioner,  such  as  a  district  office, 
requisitions  an  item  for  another  Coast  Guard  unit  and  charges  the  line  of 
accounting  data  for  that  unit,  a  fund  code  must  be  assigned  to  the  OPFAC  of  the 
district  office. 

Additionally,  the  FINCEN  uses  the  OPFAC/ fund  code  table  for  more  than 
creating  obligations.  The  table  is  used  to  modify  the  obligation  when  the  requisi¬ 
tioned  item's  price  or  quantity  changes  and  to  pay  bills.  Both  of  these  transac¬ 
tions  require  that  the  line  of  accounting  data  be  included  in  the  DAFIS 
transaction.  The  FINCEN  uses  the  OPFAC  and  fund  code  combination  from 
either  the  DLSS  status  transaction  or  the  MILSBILLS  Form  1080  to  identify  the 
proper  line  of  accounting  data  to  charge. 

The  financial  system  places  two  additional  requirements  on  the  information 
that  it  receives  from  the  requisitioning  system.  First,  the  line  of  accounting  data 
cited  by  requisitions  must  be  valid,  and  second,  obligation  information  must  be 
transmitted  to  the  DOT  financial  system  in  DAFIS  format 


Financial  Data  Edit  Check 

A  financial  data  edit  check  is  necessary  to  ensure  the  accounting  data  cited 
on  the  requisition  is  valid  because  passing  invalid  obligation  information  can  be 
expensive  when  compared  to  the  cost  of  an  edit  check.  If  the  requisitioner  cites 
an  improper  account,  the  FINCEN  must  manually  research  and  correct  the  error 
before  payments  can  be  processed,  an  activity  that  can  take  several  hours.  On  the 
other  hand,  invalid  financial  information  that  is  returned  to  the  unit  can  be  cor¬ 
rected  in  minutes. 

The  current  requisitioning  system,  ARMS,  checks  the  validity  of  the  requisi¬ 
tion's  financial  information  on  the  TCC  Amdahl  computer  before  forwarding  the 
information  to  the  financial  system.  The  edit  check  compares  the  OPFAC/ fund 
code  combination  on  the  requisition  to  the  OPFAC/ fund  code  table.  If  the  requi¬ 
sition  passes  this  edit  check,  it  is  forwarded  to  the  source  of  supply.  If  it  fails,  it  is 
returned  to  the  requisitioner  for  correction. 
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The  financial  information  on  requisitions  sent  directly  to  DAAS  is  not  edited 
before  the  requisitions  are  forwarded  to  the  source  of  supply.  Both  Coast  Guard 
and  other  Government  agency  sources  of  supply  will  process  requisitions 
regardless  of  the  fund  code  cited  on  the  requisition.  Should  these  requisitions 
possess  invalid  financial  information,  the  FINCEN  must  perform  manual 
research  to  identify  the  proper  line  of  accounting  to  charge  for  the  requisitioned 
item. 

Because  of  the  extra  effort  required  to  correct  transactions  with  invalid  infor¬ 
mation,  we  believe  that  all  data  edit  checks  should  be  done  at  the  point  at  which 
data  are  entered  into  the  system.  That  procedure  will  allow  incorrectly  input 
data  to  be  corrected  immediately  at  the  unit  level.  Also  a  unit-level  edit  check 
minimizes  the  time  necessary  to  correct  errors  so  that  requisitions  are  processed 
in  a  timely  manner  while  eliminating  the  need  for  extensive  manual  rework 
when  erroneous  data  enter  the  system. 

A  drawback  of  the  unit-level  edit  check  of  the  financial  data  in  its  current 
form  is  that  it  requires  more  computer  and  manpower  resources  than  does  the 
centralized  edit  check.  Computer  software  must  be  written  and  distributed  to 
each  unit  performing  the  edit  check.  The  edit-check  table  and  software  should  be 
designed  to  run  on  die  existing  unit-level  computer  hardware.  Additionally,  the 
edit-check  software  must  be  maintained  at  each  of  the  MMS  sites. 

The  edit-check  concerns  and  constraints  mentioned  above  highlight  two 
problems  with  placing  die  financial  data  edit  check  at  the  unit  level  in  its  current 
form  The  OPFAC/fund  code  table  in  its  current  form  is  large  (27,000  fund 
codes)  and  would  place  a  strain  on  unit-level  hardware  capacity.  Additionally, 
the  unit-level  maintenance  required  to  make  changes  to  the  table  would  be  exces¬ 
sive.  The  maintenance  of  such  a  table  would  require  the  units  to  upgrade  their 
edit  tables  each  time  a  change  is  made  to  the  table. 

We  believe  die  Coast  Guard  should  develop  an  alternative  to  the 
OPFAC/fund  code  table  that  implements  a  unit-level  edit  check  and  avoids  the 
problems  described  above.  In  the  next  subsection,  we  discuss  the  standardized 
fund  code,  an  alternative  that  we  believe  will  allow  the  financial  data  edit  check 
to  be  performed  at  the  unit  level. 


Standardized  Fund  Code 

The  current  OPFAC/  fund-code-table  concept  and  associated  ongoing  main¬ 
tenance  can  be  eliminated  by  taking  the  following  actions: 

♦  Create  a  unique  fund  code  for  each  object  class  and  allotment  fund  code 
(AFC)5  combination 


’The  AFC  identifies  an  operating  expense  appropriated  funds  category.  For  example, 
AFC-42  is  assigned  to  the  electronics  program. 
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♦  Include  the  program  element,  cost  center,  appropriation  code,  region  code, 

and  system  data  as  part  of  the  requisition. 

To  standardize  fund  codes,  one  will  be  assigned  to  every  AFC/ object-class 
combination  in  use  for  requisitioning.  On  a  requisition,  the  hind  code  will  repre¬ 
sent  both  an  AFC  and  an  object  class.  For  example.  Object  Class  2691  represents 
Navy  nonaviation  electronic  depot-level  reparables.  Both  AFC-30  and  AFC-42 
can  be  used  along  with  this  object  class  in  a  line  of  accounting  data.  Thus,  a  sepa¬ 
rate  fund  code  will  be  assigned  for  each  combination.  In  this  instance,  two  fund 
codes  will  be  assigned  —  one  for  the  combination  of  AFC-30  and  Object  Class 
2691  and  another  for  the  combination  of  AFC-42  and  Object  Class  2691. 


With  standardized  fund  codes  in  addition  to  program  element,  cost  center, 
appropriation  limitation  code,  region  code,  and  system  data  information  in¬ 
cluded  on  the  requisition,  the  FINCEN  will  have  all  necessary  information  to  as¬ 
semble  a  full  line  of  obligation  accounting  data. 


To  show  how  the  standardized  fund  code  concept  works,  we  will  use  an 
example  of  a  unit  requisitioning  an  item  (Figure  3-1).  Assume  fund  code  SA  is 
used  to  represent  Object  Qass  2634,  housekeeping  supplies  and  materials  for 
shore  units  and  cutters,  and  AFC-30.  When  a  unit,  whose  OPFAC  is  51241,  requi¬ 
sitions  a  housekeeping  item  for  itself  using  AFC-30  funds,  it  would  use  fund 
code  SA  on  the  requisition.  The  region  code  (3),  appropriation  code  (301),  pro¬ 
gram  element  (CG),  and  cost  center  (51241)  would  be  included  on  the  second 
80-character  image.  From  that  information,  the  FINCEN  would  be  able  to  assem¬ 
ble  the  line  of  accounting  data  from  the  requisition. 


Requisition  Data  Line  of  Accounting  Data 


Figure  3-1. 

Translating  Requisition  Information  into  Line  of  Accounting  Data 


Until  the  Coast  Guard  converts  its  transactions  to  DLMS,  a  second 
80-character  image  will  be  used  to  transmit  the  additional  data  within  the  Coast 
Guard,  but  only  the  information  on  the  standard  requisition  will  be  sent  to  the 
source  of  supply.  The  standard  requisition  plus  the  80-character  image  will  be 
sent  to  the  FINCEN.6  (Note:  Under  DLMS,  the  additional  data  can  be  easily 

‘The  two  80-character  images  are  related  to  each  other  by  the  common  requisition 
number  on  both  80-character  images. 
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accommodated  as  Service-specific  data  and  made  part  of  the  Coast  Guard  stan¬ 
dard  requisition  format.) 

Subsequent  DLSS  transactions,  such  as  price  and  quantity  changes,  cancella¬ 
tions,  and  bills  received  from  the  source  of  supply,  will  require  the  original  obli¬ 
gation  to  be  modified  or  expended.  Until  DLMS  Version  2.0  is  implemented, 
these  transactions  will  only  contain  the  standard  requisition  data,  and  a  full  line 
of  accounting  data  can  only  be  created  by  accessing  data  from  the  original 
requisition.  To  do  so,  a  system  that  links  these  new  transactions  to  the  line  of 
accounting  data  on  the  original  requisition  must  be  created.  Then,  when  the 
Coast  Guard  FINCEN  received  a  DLSS  transaction  that  modifies  the  obligation, 
the  transaction  will  be  crossed  to  the  line  of  accounting  data  used  to  create  the 
original  obligation.  After  the  implementation  of  DLMS  Version  2.0,  the  addi¬ 
tional  financial  information  will  be  included  in  the  transaction. 

The  system  that  identifies  the  line  of  accounting  data  for  those  transactions 
that  modify  or  complete  an  obligation  must  create  a  file  to  link  the  line  of 
accounting  data  with  the  requisition  number.  The  file  will  cross-reference  the 
document  number  from  the  obligation  modification  transactions  to  the  original 
line  of  accounting  data.  All  obligation  modification  transactions  from  the  source 
of  supply  and  the  requisitioning  unit  are  processed  automatically  by  DAAS. 
Those  transactions  can  be  automatically  sent  and  processed  by  the  system  that 
links  the  document  number  to  the  line  of  accounting  data.  Bills  that  complete  the 
obligation  are  typically  sent  directly  to  the  FINCEN  from  the  source  of  supply  in 
a  nonautomated  format  This  file  should  either  be  physically  located  with,  or  be 
accessible  to,  the  DAFIS  translator  that  we  discuss  later  in  this  report 


Conclusion 


By  adopting  the  standardized  fund  code  described  above,  the  Coast  Guard 
can  perform  the  financial  data  edit  check  at  the  unit  level;  that  action  will  reduce 
the  total  number  of  Coast  Guard  fund  codes  and  facilitate  training  in  the  use  of 
fund  codes  because  the  same  fund  code  relationship  will  apply  to  every  unit  in 
the  Coast  Guard. 


Rbcommendatton 


We  recommend  that  the  Logistics  Management  Division  (G-ELM),  Office  of  Engi¬ 
neering  and  Logistics  Development  (G-E),  working  in  partnership  with  the  Financial 
Management  Division  (G-CFM),  place  the  responsibility  for  the  requisition-related 
financial  data  edit  check  at  the  unit  level.  At  that  level,  if  data  are  incorrectly  input, 
they  can  be  corrected  immediately.  A  unit-level  edit  check  will  minimize  the  time 
necessary  to  correct  errors  so  that  requisitions  can  be  processed  in  a  timely  man¬ 
ner  and  the  need  for  extensive  manual  rework  when  erroneous  data  enter  the 
system  will  be  eliminated. 
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We  recommend  that  the  Financial  Management  Division  (G-CFM)  eliminate  the 
OFF  AC/fund  code  table  and  replace  it  with  the  standardized  fund  code  proposed  here. 
Implementation  of  the  standardized  fund  code  will  require  the  following  actions: 

♦  The  Coast  Guard  must  standardize  relationships  between  fund  codes,  object 
classes,  and  AFCs. 

♦  The  units  must  include  the  following  additional  information  with  the  requi¬ 
sition: 

►  Program  element 

►  Cost  center 

►  Appropriation  limitation  code 

►  Region  code 

►  System  data. 

♦  The  capability  to  convert  requisition  financial  data  into  a  full  line  of  account¬ 
ing  data  must  be  developed. 

♦  A  link  must  be  maintained  between  obligation  data  and  requisition  number. 


DAFIS  Format 


The  DAFIS  was  developed  in  1986  as  the  replacement  system  for  the  Uni¬ 
form  Accounting  System.  DAFIS  is  the  DOT'S  single  data  base  for  financial  infor¬ 
mation.  All  agencies  within  the  DOT,  including  the  Coast  Guard,  are  required  to 
submit  thei^  financial  and  accounting  transactions  to  the  DAFIS  computer  center 
in  Plano,  Texas.  DAFIS  provides  on-line  access  for  inquiries  and  standard  reports 
to  Coast  Guard  financial  managers. 

Currently,  the  TCC  Amdahl  computer  creates  and  transmits  a  320-character, 
fixed-length,  DAHS-fcrmatted  transaction  for  every  DLSS  requisition  it  receives. 
When  the  TCC  Amdahl  computer  receives  a  DLSS  transaction,  it  matches  the 
transaction's  OPFAC/ fund  code  combination  to  the  fund  code  table  to  identify 
the  line  of  accounting  data  it  should  include  on  the  transaction.  The  TCC 
Amdahl  computer  then  converts  the  incoming  DLSS  transaction  type  into  a  cor¬ 
responding  DAFIS-formatted  transaction  type  (e.g.,  it  generates  an  obligation 
transaction  when  a  requisition  is  received). 

The  MMS  will  continue  to  provide  requisition-related  financial  information 
to  the  DAFIS  computer  center  in  DAFIS  format.  It  must  generate  a 
DAFIS-formatted  transaction  for  every  DLSS  transaction  that  affects  the  financial 
system  (requisition,  price  change,  quantity  change,  or  cancellation). 
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The  two  alternative  approaches  for  transmitting  requisition-related  informa¬ 
tion  to  DAFIS  are  as  follows: 

♦  Generate  and  transmit  DAFIS-formatted  transactions  from  the  source  of  the 
DLSS  transaction 

♦  Develop  a  translator  for  the  front  end  of  DAFIS  to  interpret  the  DLSS  trans¬ 
action  and  create  a  DAFIS-formatted  transaction. 


Transmitting  DAFIS  Transactions  from  the  Source 

Under  the  first  alternative,  the  creator  of  any  MMS  transaction  requiring 
financial  system  updates  sends  a  DAFIS-formatted  transaction  to  the  DAFIS 
computer  center  to  report  that  transaction  That  procedure  differs  from  current 
ARMS  practices  in  which  all  requisition-related  DAFIS  input  transactions  are  cre¬ 
ated  and  sent  from  a  central  source. 

In  this  alternative,  for  example,  when  a  requisition  is  created,  the  requisi- 
tioner  will  not  only  submit  the  requisition  via  DAAS  to  the  source  of  supply,  but 
will  also  transmit  a  320-character  DAFIS-formatted  obligation  transaction  to  die 
DAFIS  computer  center.  The  same  procedures  will  be  implemented  for  the  trans¬ 
mission  of  any  requisition  status  transactions  from  the  source  of  supply  having 
financial  impacts.  The  source  of  supply  will  send  a  DAFIS-formatted  transaction 
to  the  DAFIS  computer  center  in  addition  to  the  DLSS  status  transaction. 


DAFIS  T  RANSLATOR 

The  second  alternative  for  providing  requisition-related  financial  informa¬ 
tion  to  the  DAFIS  computer  center  is  to  develop  a  DAFIS  translator.  The  transla¬ 
tor  software  will  be  able  to  convert  the  incoming  DLSS  transaction  (in  either 
DLSS  or  DLMS  format)  and  its  line  of  accounting  information  to  a  320-character 
DAFIS  transaction. 

The  translation  process  must  be  sequentially  performed  after  the  line  of 
accounting  data  from  the  original  requisition  has  been  identified.  The  primary 
functional  consideration  is  that  the  translator  connect  the  requisitioning  and 
financial  systems  by  being  capable  of  receiving  requisition-related  financial 
information  from  both  the  requisitioner  and  the  source  of  supply. 


Conclusions 


We  believe  the  DAFIS  translator  is  the  most  practical  way  to  send  all 
DAFIS-formatted,  requisition-related  transactions  to  the  DAFIS  computer  center. 

We  further  believe  the  scope  of  MMS  enables  it  to  create  a  procedure  to 
transmit  DAFIS-formatted  transactions  from  Coast  Guard  requisitioning  units. 
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However,  it  would  not  be  practical  or  possible  to  require  other  Government 
agencies  to  create  and  transmit  DAFIS-formatted  transactions  because  those 
transactions  are  beyond  the  scope  of  envisioned  capabilities,  and  DAFIS  format 
is  not  compatible  with  either  the  DLMS  or  DLSS  transaction  formats.  The  transla¬ 
tor  would  be  invisible  to  the  users  of  MMS.  It  would  interpret  exiting  transac¬ 
tions  and  would  not  force  users  of  MMS  (especially  other  Government  agencies) 
to  alter  the  format  of  their  communications  transactions.  Requisition-related 
transactions  in  DLSS  format  can  be  processed  the  same  for  the  Coast  Guard  as 
any  other  Federal  requisitioner. 

We  believe  that  the  translator  should  be  capable  of  converting  all  requisi¬ 
tions,  modifications,  cancellations,  and  bills  into  a  DAFIS  transaction.  It  should 
be  collocated  with,  or  communicate  with,  the  process  that  converts  information 
on  requisition  transactions  into  lines  of  accounting  data.  It  should  be  able  to 
receive  requisition  transactions  from  Coast  Guard  units,  requisition  modification 
and  cancellation  transactions  from  DAAS,  and  billing  information  from  the 
FINCEN. 


Recommendation 


We  recommend  that  the  Coast  Guard  develop  and  maintain  translator  software  to 
convert  DLSS  transactions  into  DAFIS-formatted  transactions.  The  DAFIS  translator 
must  be  capable  of  recognizing  and  converting  transactions  in  both  DLMS  and 
DLSS  formats. 


Location  of  the  Financial  Translators 

We  recommend  that  the  Coast  Guard  establish  two  translators  to  interpret 
and  convert  financial  information.  Those  translators  represent  two  steps  in  the  fi¬ 
nancial  translation  process  that  converts  requisition  transactions  into  formats 
understandable  to  the  DOT  financial  system.  The  first  step  of  this  financial  trans¬ 
lation  process  interprets  the  financial  information  on  a  requisition  and  creates  a 
line  of  accounting  data;  the  second  step  converts  the  transaction  and  line  of 
accounting  data  into  a  DAFIS  transaction.  The  financial  translator  must  also 
maintain  a  file  that  links  the  requisition's  document  number  with  the  obligation's 
line  of  accounting  data  so  that  the  proper  line  of  accounting  data  can  be  identi¬ 
fied  on  subsequent  modifications.  In  tire  following  subsections,  we  discuss  the 
merits  of  two  alternative  locations  for  the  financial  translator. 


Financial  Translator  at  a  Central  Location 

In  this  alternative,  the  financial  translator  would  not  be  located  at  the 
FINCEN  but  rather  at  another  single  central  site  possessing  adequate  computer 
resources.7  All  MMS  transactions  that  affect  financial  obligations  would  be 

7TCC  and  the  Operations  Systems  Center,  Martinsburg,  W.  Va.,  may  be  examples  of 
central  location  alternatives  that  possess  adequate  computer  resources. 
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routed  to  this  translator  so  that  a  DAFIS  transaction  could  be  created.  The  pri¬ 
mary  benefit  of  using  a  central  site  is  that  by  utilizing  its  current  computing 
facilities,  the  Coast  Guard  would  not  have  to  acquire  additional  computing 
capacity. 

The  bill-paying  process  is  a  major  obstacle  to  placing  the  financial  translator 
at  a  central  site.  Bills  that  complete  the  obligation  are  sent  to  the  FINCEN  in  a 
non-uniform  format  They  are  received  electronically  and  by  mail  in  paper  form. 
To  complete  the  bill-paying  process,  the  FINCEN  must  have  access  to  the  trans¬ 
action  stored  at  the  central  site.  Additionally,  the  FINCEN  would  have  to 
develop  a  capability  to  update  the  central  site  with  the  data  needed  to  create 
DAFIS  expenditure  transactions. 


Financial  Translator  at  the  Finance  Center 

In  addition  to  submitting  transactions  to  DAFIS  for  requisitions,  the 
FINCEN  submits  obligation  transactions  for  commercial  purchases.  The  require¬ 
ment  to  submit  those  obligation  transactions  will  continue  regardless  of  where 
the  financial  translator  is  located.  Placing  the  financial  translator  at  a  site  other 
than  the  FINCEN  would  entail  duplicative  processes. 

The  FINCEN  does  not  have  sufficient  computer  resources  to  accommodate 
the  financial  translator.  If  the  financial  translator  is  placed  at  the  FINCEN  rather 
than  at  another  site,  the  FINCEN  will  have  to  acquire  additional  computer  capac¬ 
ity. 


Conclusion 


We  believe  that  placing  the  financial  translator  at  a  central  site  will  unneces¬ 
sarily  duplicate  processes.  We  recommend  that  die  financial  translator  be  placed 
at  the  FINCEN  for  the  following  reasons: 

♦  Billing  data  are  not  submitted  in  a  standard  format  Thus,  if  the  financial 
translator  were  placed  at  a  central  site,  the  FINCEN  would  have  to  access 
and  interpret  central  site  transaction  data  for  the  FINCEN  to  complete  the 
bill  paying,  and  it  would  subsequently  have  to  input  the  data  the  central  site 
needs  to  create  the  DAFIS  expenditure  transaction.  The  organization  to  per¬ 
form  those  actions  exists  at  the  FINCEN  and  will  remain  there  to  input  com¬ 
mercial  billing  information. 

♦  The  Coast  Guard  should  maintain  a  single  interface  with  DAFIS.  Regardless 
of  where  the  financial  translator  is  located,  the  FINCEN  will  continue  to 
input  commercial  purchase  transactions  to  DAFIS. 
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Recommendation 


We  recommend  that  the  Coast  Guard  place  the  financial  translator  at  the  FINCEN. 
The  financial  translator  must  be  capable  of  converting  requisitions  into  a  full  line 
of  accounting  data  and  creating  a  DAF1S  input  transaction. 


Data-Collection  Requirement 

Materiel  Management  System 

The  requirement  that  MMS  capture  and  record  requisition  and  commercial 
purchase  information  is  an  important  feature  that  distinguishes  it  from  ARMS. 
In  addition  to  transmitting  requisitions  as  ARMS  does  today,  MMS  will  main¬ 
tain  a  data  base  that  will  collect  and  provide  access  to  the  following: 

♦  Historical,  unit-level  requisitioning  and  commercial-purchase  information 

♦  Current  status  of  unit-level  requisitions  and  commercial  procurements 

♦  Staging  information  on  materiel  for  use  in  scheduled  maintenance  or  in 
transit  to  afloat  units.8 

The  MMS  data  base  will  provide  data  for  supply  managers  to  use  for  requi¬ 
sitioning  and  supply  system  performance  analysis.  It  can,  for  example,  be  used 
to  identify  the  responsiveness  of  the  requisitiop^g  '.ystem  in  terms  of  time  nec¬ 
essary  to  process  requisitions  or  the  responsiveness  of  the  supply  system  to  unit 
needs.  It  will  also  provide  visibility  of  active  requisition  and  commercial  pur¬ 
chase  actions.  That  will  allow  unit,  maintenance,  and  supply  managers  to  track 
the  status  of  procurements  from  the  time  the  item  is  ordered  until  it  is  received. 

On  many  occasions,  such  as  a  maintenance  availability  and  overhauls,  ma¬ 
teriel  requirements  are  identified  and  requisitions  are  placed  well  in  advance  of 
the  date  the  materiel  is  needed.  As  the  requisitioned  materiel  arrives,  it  is  stored 
by  various  activities  until  it  is  needed  to  perform  die  maintenance  action.  The 
MMS  data  base  will  provide  storage  information  to  account  for  such  items  being 
held  for  scheduled  maintenance.  In  addition  to  scheduled  maintenance  avail¬ 
abilities,  the  MMS  data  base  will  also  maintain  staging  information  for  materiel 
awaiting  the  return  of  an  afloat  unit  horn  a  deployment 


Parts  Tracking  System 

Concurrent  with  our  analysis  of  the  requirements  of  MMS,  the  Vessel  Divi¬ 
sion  of  Maintenance  and  Logistics  Command  Atlantic  [MLCA(v)]  and  VNTSC 
have  defined  the  requirements  for  a  repair  Parts  Tracking  System.  The  objective 
of  the  Parts  Tracking  System  is  to  "track  the  status  of  Government  Furnished 

*  Fleet  Logistics  System  (FLS)  Conceptual  Architecture  Report  (CAR)  (draft),  op.  cit. 
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Equipment  (GFE)  for  availabilities  and  parts  to  restore  unit  casualty  reports 
(CASREPs)  over  the  complete  parts  tracking  life  cycle."9 

The  Parts  Tracking  System  (Figure  3-2)  defines  a  set  of  life  cycle  processes 
that  materiel  needed  for  availabilities  and  CASREPs  follow.  The  life  cycle  starts 
with  the  identification  of  the  necessary  parts  for  the  maintenance  and  continues 
through  the  final  disposition  of  die  materiel.  The  Parts  Tracking  System  pro¬ 
vides  managers  visibility  of  repair  parts  as  they  process  through  the  stages  of 
the  Parts  Tracking  System  life  cycle. 


Figure  3-2. 

Parts  Tracking  System  Life  Cycle  Processes 

Functional  Differences  Between  the  Materiel  Management  System 
and  the  Parts  Tracking  System 

The  Parts  Tracking  System  and  MMS  have  several  areas  of  common  inter¬ 
est  They  both  seek  to  provide  visibility  of  materiel  movement  during  the  requi¬ 
sitioning  and  commercial  purchasing  processes.  The  difference  between  the  two 
systems  is  in  die  range  of  materiel  tracked.  MMS  seeks  to  provide  visibility  of  all 
materiel  being  acquired  by  Coast  Guard  units;  die  Parts  Tracking  System  ad¬ 
dresses  only  materiel  needed  for  availabilities  and  CASREPs. 

Additionally,  the  Parts  Tracking  System  maintains  visibility  over  more  proc¬ 
esses  than  does  MMS.  MMS  visibility  begins  at  the  point  at  which  a  requisition 
is  created,  while  the  Parts  Tracking  System  includes  planning  processes  involv¬ 
ing  the  identification  of  die  materiel  need  and  source  of  supply.  MMS  stops 
tracking  items  when  the  materiel  is  delivered  to  the  end  user. 


*  Parts  Tracking  Requirements  Study  -  Interim  Requirements  Analysis  Briefing,  Battelle 
Memorial  Institute,  10  March  1992. 
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Alternative  Data-Collection  Systems 

In  the  next  two  subsections,  we  describe  two  alternatives  for  collecting  data 
generated  by  MMS:  the  Logistics  Information  Processing  System,  and  the  logis¬ 
tics  intelligence  file. 


Logistics  Information  Processing  System 

In  addition  to  processing  and  forwarding  transactions,  DAAS  is  responsible 
for  archiving  them  and  providing  management  information  on  supply  system 
operations.  In  the  past,  the  archiving  medium  has  been  magnetic  tape.  Future 
operations,  however,  will  provide  interactive  availability  of  transactions  via  the 
Logistics  Information  Processing  System  (LIPS)  for  several  months  and  long¬ 
term  archiving  on  optical  disks.  Data  can  be  retained  on  optical  disks  for  longer 
periods  and  is  more  readily  available  to  meet  user  requirements. 

The  LIPS  is  a  new  service  that  will  be  offered  by  the  Defense  Automatic 
Addressing  System  Center  (DAASQ.  It  will  be  an  on-line  interactive  data  base 
of  all  transactions  that  pass  through  DAAS.  The  following  are  some  of  its  key 
characteristics: 

♦  It  operates  on  an  IBM  mainframe  computer  using  the  DB2  data  base  man¬ 
agement  system.10 

♦  It  supports  the  standard  query  language  with  both  standard  query  screens 
and  user-defined  queries.  It  generates  standard  and  custom  reports. 

♦  Beginning  early  in  FY94,  its  data  base  will  be  available  24  hours  a  day,  every 
day. 

♦  Communications  can  be  through  die  Defense  Data  Network  or  any  com¬ 
mercial  means  to  the  system  telephone  number  in  Dayton,  Ohio.  Any  termi¬ 
nal  that  can  emulate  a  3270/  ASCII  (American  Standard  Code  for 
Information  Interchange)  protocol  can  be  used  to  access  die  system. 

♦  Transactions  remain  on  the  system  for  varying  lengths  of  time  but  typically 
for  90  - 120  days. 

♦  Security  level  is  C2  based  on  National  Security  Agency  classification  levels. 
Access  is  based  on  user  identification  and  password. 

The  most  significant  retention  period  from  an  MMS  viewpoint  is  that  for  the 
requisition.  Requisitions,  follow-ups,  supply  status,  and  shipment  status  trans¬ 
actions  will  be  maintained  on  the  system.  They  will  be  maintained  on  line  for 


10DB2  is  a  proprietary  IBM  Corporation  mainframe  computer  data  base  management 
system. 
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120  days  after  closeout.  When  transactions  are  moved  off  line,  they  are  trans¬ 
ferred  to  optical  disks  where  they  can  still  be  accessed. 

The  DAASC  can  provide  custom  support  to  meet  Coast  Guard-unique  re¬ 
quirements.  Charges  to  the  Coast  Guard  for  either  standard  or  special  services 
would  be  negotiated  through  an  interagency  agreement 

Another  facet  of  LIPS  will  be  its  effect  on  the  Military  Standard  Evaluation 
Procedure,  which  provides  management  information  to  Service,  agency,  and 
Office  of  the  Secretary  of  Defense  managers  on  the  performance  of  the  DoD  sup¬ 
ply  system.  Currently,  DoD  ICPs,  depots,  and  other  activities  provide  data  to 
DAASC  that  consolidates  the  information  and  provides  it  to  DoD  managers.  His¬ 
torically,  such  information  has  been  provided  in  the  form  of  voluminous  data- 
filled  reports.  The  implementation  of  LIPS  and  associated  software  tools  will  al¬ 
low  DAASC  to  tailor  reports  in  terms  of  data  to  be  presented  and  presentation 
format. 


Logistics  Intelligence  File 

An  LIF  is  a  generic  term  used  for  a  file  such  as  LIPS  to  collect  logistics  data. 
LIFs  are  used  by  several  Services  within  DoD  to  capture  Service-specific  logistics 
information.  In  this  subsection,  we  show  an  example  of  how  the  Army  uses  an 
LIF  and  how  an  LIF  tailored  to  Coast  Guard  needs  might  look. 


Army  Logistics  Intelligence  File 

The  Army  Materiel  Command  maintains  an  LIF  at  its  Logistics  Control 
Activity  (LCA)  at  the  Presidio  of  San  Francisco,  Cal.11  The  LIF  is  the  Army' s  cen¬ 
tral  data  bank  for  supply  and  transportation  information,  and  it  provides  visibil¬ 
ity  of  requisitions  and  shipments  as  they  are  processed. 

The  LIF  provides  materiel  visibility  to  units  and  various  supply  mangers 
throughout  the  Army.  Information  is  provided  to  the  LDF  at  each  step  of  the  req¬ 
uisition  cycle  from  the  time  the  requisition  is  created  until  the  materiel  is 
received  by  the  requisitioner.  Data  are  input  to  the  LIF  from  DAAS,  from  activi¬ 
ties  that  consolidate  materiel  and  shipments  along  the  transportation  pipeline, 
from  ports  of  embarkation  for  overseas  shipments,  and  from  ports  of  debarka¬ 
tion.  Each  of  those  activities  sends  electronic  transactions  to  the  LIF  to  update  the 
status  of  the  materiel. 

Information  in  the  LIF  is  accessible  24  hours  a  day  in  standard  or  custom 
designed  periodic  reports  and  on-line  inquiry.  Inquiry  methods  range  from  batch 


11  Army  planning  for  consolidations  and  reorganizations  includes  relocating  the  LCA 
and  consolidating  it  and  several  field  agencies  to  form  a  new  Logistics  Operations  Sup¬ 
port  Activity.  One  location  being  considered  is  Huntsville,  Ala.  The  Army  plans  to  con¬ 
tinue  operating  the  LIF  until  a  final  decision  is  made  on  integrating  it  into  LIPS. 
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AUTODIN  requests  from  field  units  that  have  many  requests  to  interactive 
inquiries  from  remote  sites  having  few  requests. 


Gust  Guard  Logistics  Intelligence  File 

Using  the  example  of  the  Army's  LIF,  we  can  generalize  the  LEF  concept  and 
apply  it  to  the  Coast  Guard's  specific  needs.  The  CGLIF  will  be  the  central 
source  of  tracking  and  historical  information  on  requisitions  and  commercial 
procurements.  It  will  be  designed  around  data  received  from  the  requisition  and 
commercial  procurement  processes.  The  CGLIF  will  receive  copies  of  all  transac¬ 
tions  from  the  requisitioning  process  and  create  a  record  for  a  particular  requisi¬ 
tion  so  that  it  may  be  tracked.  After  the  materiel  has  been  received  by  the  end 
user,  the  record  will  be  closed  and  archived  into  the  historical  file.  Figure  3-3 
shows  how  inputs  will  be  received  by  the  CGLIF. 


Figure  3-3. 

Flow  of  Input  Data  to  the  CGUF 


The  DAAS  will  be  instructed  to  send  the  CGLIF  a  copy  of  all  Coast  Guard 
transactions  that  it  receives.  When  a  requisition  is  created,  DAAS  will  send  a 
copy  of  the  requisition  to  the  CGLIF  as  it  passes  the  requisition  to  the  source  of 
supply.  Similarly,  it  will  send  the  CGLIF  a  copy  of  all  status  transactions  received 
from  the  source  of  supply.  When  the  source  of  supply  ships  an  item  to  an  inter¬ 
mediate  destination,  such  as  a  shore  support  activity,  that  activity  sends  CGLIF  a 
transaction  to  update  the  status  of  the  requisition. 

The  MMS  and/or  associated  Coast  Guard  unit  procurement  systems  will 
generate  transactions  conveying  commercial  purchase  data.  The  initiating  unit 
may  transmit  those  actions  to  the  CGLIF  either  through  DAAS  or  directly.12  The 


“The  method  used  to  transmit  commercial  purchase  information  from  the  unit  to  the 
CGLIF  depends  on  future  telecommunications  decisions.  Additionally,  a  possible  alterna¬ 
tive  to  the  unit  inputting  commercial  purchase  transactions,  is  to  have  die  CGLIF  periodi¬ 
cally  draw  data  from  the  unit. 
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transactions  may  be  submitted  in  any  format  convenient  to  the  Coast  Guard. 
However,  using  ASC  X12  EDI  would  be  an  effective  choice  if  the  Coast  Guard 
implements  EDI  in  commercial  procurement.  In  addition  to  reporting  and  updat¬ 
ing  the  procurement  action,  intermediate  destinations  will  report  the  receipt  and 
disposition  of  the  materiel  received  from  commercial  purchases  in  the  same  man¬ 
ner  as  requisitions.  All  commercial  purchase  transaction  formats  must  be  devel¬ 
oped  by  die  Coast  Guard  and  must  contain  information  necessary  to  both  track 
the  status  of  die  item  and  analyze  the  purchase  from  an  historical  perspective. 

After  the  procurement  transaction  (requisition  or  commercial  purchase)  is 
completed,  the  CGLIF  record  will  be  archived,  and  the  historical  records  main¬ 
tained  by  the  CGLIF  will  be  available  for  future  analysis. 

The  information  in  the  CGLIF  can  be  made  accessible  to  anyone.  Various 
individuals  within  the  Coast  Guard,  from  unit-level  personnel  to  supply  and 
maintenance  managers  at  Maintenance  and  Logistics  Commands  and  Headquar¬ 
ters,  are  expected  to  have  some  access  to  the  data.  The  information  that  a  parti¬ 
cular  individual  can  access  and  the  media  used  to  access  the  CGLIF  must  be 
established  on  the  basis  of  user  needs.  Some  of  the  numerous  ways  that  desig¬ 
nated  users  can  access  the  CGLIF  data  base  are  as  follows: 

♦  Batch  or  interactive  electronic  inquires  through  the  standard  workstation 

♦  Automatic  generation  of  standard  periodic  reports 

♦  Voice  telephone  or  electronic  mail  inquiries  to  a  customer  service  organiza¬ 
tion  that  has  access  to  the  CGLIF. 

As  the  FLS  is  built,  the  Coast  Guard  can  use  the  CGLIF  data  in  other  FLS 
applications  such  as  the  performance  management  application.  That  application 
will  be  used  to  evaluate  logistics  system  performance  for  the  critical  success  tec- 
tors  of  each  logistics  organization.  The  supply  transaction  data  in  CGLIF  will  be 
one  of  several  useful  data  bases  needed  for  the  performance  management  appli¬ 
cation. 


Conclusion 


The  primary  advantage  of  LIPS  is  that  the  Coast  Guard  will  be  able  to  satisfy 
its  need  for  a  data-collection  system  while  taking  advantage  of  economies  of 
scale  provided  by  the  DAASC.  Because  LIPS  will  be  developed  by  the  DAASC 
and  available  to  all  users  of  DLSS/DLMS,  the  Coast  Guard  will  only  be  charged 
for  that  portion  of  the  system  it  uses.  The  fixed  hardware,  software  development, 
and  management  costs  will  be  spread  over  a  wider  range  of  users  than  if  the 
Coast  Guard  were  to  develop  a  system  on  its  own. 

However,  LIPS  is  limited  by  the  same  factors  that  make  it  a  potentially  lower 
cost  alternative.  Although  LIPS  can  be  flexible  and  provide  custom  support  for 
Coast  Guard-unique  requirements,  the  UPS  data  base  contains  only  data  from 
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DLSS/DLMS  transactions.  Important  categories  of  transactions,  commercial  pur¬ 
chases,  and  intra-Coast  Guard  materiel  movement  and  storage  transactions,  will 
not  be  captured  by  the  UPS  data  base. 

CGLIF,  on  the  other  hand,  can  be  tailored  to  Coast  Guard  needs.  It  can  main¬ 
tain  all  the  information  that  passes  through  DAAS  and  can  maintain  commercial 
purchase  and  staging  information.  Additionally,  the  ultimate  control  over  access 
and  maintenance  of  the  data  is  within  the  Coast  Guard.  The  establishment  of  a 
CGLIF  eliminates  the  risk  of  losing  access  to,  or  control  of,  MMS  data  based  on 
decisions  made  external  to  the  Coast  Guard.  That  consideration  is  extremely 
important  when  using  the  CGLIF  as  the  source  of  supply  support  oversight. 

As  we  previously  defined  it,  MMS  will  transmit  requisitions  and  collect  and 
provide  access  to  materiel  tracking  and  staging  information  for  requisitions  and 
commercial  purchases.  In  other  words,  MMS  is  a  subset  (order  parts,  receive  and 
inspect,  and  stage  processes)  of  the  Parts  Tracking  System. 

The  maintenance  community  will  be  a  major  consumer  of  the  data  provided 
by  the  MMS  data  collection  system.  The  Parts  Tracking  System  is  a  description  of 
how  maintenance  managers  plan  to  manage  maintenance  materiel.  It  serves  as  a 
framework  to  communicate  the  materiel  needed  for  maintenance  actions,  com¬ 
municate  the  plans  to  fill  the  need,  and  monitor  the  execution  of  the  plan.  Several 
processes  in  the  Parts  Tracking  System  life  cycle  (order  parts,  receive  and  inspect, 
and  stage)  duplicate  MMS  processes.  To  successfully  support  maintenance  plan¬ 
ning,  the  MMS  data-collection  system  should  be  capable  of  supporting  this  sys¬ 
tem. 


Recommendations 

We  recommend  that  the  Coast  Guard  establish  a  logistics  intelligence  file  to  capture 
all  requisition  and  commercial  purchase  information.  The  CGLIF  should  provide  his¬ 
torical  requisitioning  and  commercial  purchasing  data  for  analysis  by  supply 
and  maintenance  managers.  The  CGLIF  will  provide  visibility  of  all  active  requi¬ 
sitioning  and  commercial  purchasing  transactions  so  that  supply  and  mainte¬ 
nance  managers  can  track  the  movement  of  materiel.  In  addition  to  tracking 
materiel,  the  CGLIF  will  provide  Coast  Guard  managers  the  data  needed  to 
evaluate  commercial  and  Federal  Supply  System  performance.  This  data  base 
will  contain  all  requisitioning  transactions  (e.g.,  requisition,  status,  and  shipment 
transactions)  and  commercial  procurement  information. 

We  recommend  CGLIF  over  the  LIPS  because  CGLIF  can  be  tailored  to 
Coast  Guard  needs.  It  can  capture  all  commercial  purchase  and  staging  informa¬ 
tion  in  addition  to  DLSS  transactions.  Additionally,  the  ultimate  control  over 
access  and  maintenance  of  the  data  remains  within  the  Coast  Guard.  The  estab¬ 
lishment  of  a  CGLIF  eliminates  the  risk  of  losing  access  to,  or  control  of,  MMS 
data  based  on  decisions  made  external  to  the  Coast  Guard. 
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We  also  recommend  that  the  design  of  the  CCLIF  recognize  the  data  requirements  of 
the  Parts  Tracking  System.  The  Parts  Tracking  System  has  a  detailed  description  of 
how  the  maintenance  community  plans  to  track  repair  part  information.  MMS 
will  be  a  primary  source  of  requisition  and  commercial  purchase  information  for 
maintenance  materiel. 

We  recommend  that  the  program  manager  of  the  Systems  to  Automate  and  Integrate 
Logistics  (SAIL)  project  monitor  the  development  of  both  MMS  and  the  Parts  Tracking 
System  projects  to  ensure  functional  consistency  and  prevent  duplication  of  process. 
MMS  and  the  Parts  Tracking  System  contain  some  common  processes.  Specifi¬ 
cally,  the  order  parts,  receive  and  inspect,  and  stage  process  of  the  Parts  Tracking 
System  life  cycle  defined  by  the  Parts  Tracking  System  are  primary  MMS  proc¬ 
esses.  MMS  is  intended  to  be,  and  should  be,  the  requisitioning  and  data- 
collection  system  for  all  Coast  Guard  materiel.  The  developers  of  the  Parts  Track¬ 
ing  System  should  recognize  that  fact  and  not  create  a  duplicate  requisitioning, 
receiving,  and  staging  system  for  materiel  needed  for  dockside  maintenance, 
availabilities,  and  CASREPs.  Similarly,  the  developers  of  MMS  should  recognize 
and  include  the  data  requirements  of  the  maintenance  community  in  MMS. 


Communications  Requirements 

Current  ARMS  procedures  require  users  to  send  and  receive  transactions 
over  commercial  telephone  lines  or  over  an  x.25  Coast  Guard  Data  Network  con¬ 
nection.  To  do  so,  all  users  must  have  access  to  a  commercial  telephone  line  or 
cellular  phone  for  requisitioning.  Such  access  poses  no  problem  to  shore  units 
that  have  available  commercial  telephone  service.  On  afloat  units,  however, 
where  commercial  telephone  lines  are  in  short  supply  or  not  available,  ARMS 
requisitioning  procedures  are  impractical. 

Because  they  do  not  have  telephone  facilities,  afloat  units  commonly  send 
message  requisitions  directly  to  DAAS,  which  circumvents  the  ARMS  requisition 
processing.  Those  requisitions  do  not  pass  through  the  financial  edit  check,  and 
required  financial  information  is  not  passed  on  to  the  DAF1S  computer  center  to 
create  an  obligation  before  the  requisition  is  received  by  the  source  of  supply.13 

A  properly  designed  MMS  must  be  more  accessible  to  users  than  ARMS.  It 
should  provide  a  communications  gateway  so  that  all  units  can  use  MMS  under 
normal  working  conditions.  It  should  evolve  to  the  only  requisitioning  system 
used  by  Coast  Guard  units  ashore  and  at  sea. 

The  communications  capabilities  of  MMS  must  be  flexible  enough  to  accom¬ 
modate  the  needs  of  both  shore  and  afloat  units,  and  its  procedures  should  be 
simple  enough  to  encourage  its  use.  Communication  procedures  that  include  all 
units  and  situations  will  ensure  compliance  with  MMS  procedures.  Burdensome 


13  When  the  source  of  supply  sends  requisition  status  back  to  the  unit,  DAAS  sends  a 
copy  to  ARMS  to  create  an  obligation. 
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communication  procedures  will  discourage  units  use  of  MMS  and  diminish  its 
effectiveness. 

The  following  subsections  describe  two  MMS  communication  alternatives: 
sending  transactions  directly  to  DAAS  and  using  the  Navy-developed  Stream¬ 
lined  Automated  Logistics  Transmission  System  (SALTS). 


Sending  Transactions  Directly  to  the  Defense  Automatic 
Addressing  System 

Requisitions 


The  MMS  transactions  may  be  transmitted  by  sending  requisitions  directly 
to  the  DAAS  and  using  it  as  a  routing  hub.  It  will  be  requested  to  send  copies  of 
requisitions  that  it  receives  to  the  data-collection  system,  the  financial  system, 
and  the  source  of  supply. 

As  Figure  3-4  shows,  the  requisitioning  unit  will  send  the  requisition 
directly  to  DAAS,  which  will  be  instructed  to  receive  the  requisition,  send  a  copy 
to  the  CGLIF  and  the  FINCEN,  and  forward  the  requisition  to  die  source  of  sup¬ 
ply.  Status  information  coming  back  from  the  source  of  supply  will  be  sent  to  the 
requisitioner,  the  CGLIF,  and  to  the  FINCEN  (if  it  contains  financial-related  in¬ 
formation).  Requisitioning  units  at  sea  will  continue  to  send  requisitions  to 
DAAS  by  message. 


Commercial  Purchases 

The  transmission  system  described  in  Figure  3-4  can  accommodate  the 
requirement  of  MMS  to  store  and  maintain  visibility  of  commercial  purchasing 
information  if  the  Coast  Guard  requests  DAAS  to  convey  those  data.  Use  of  this 
alternative  would  require  the  Coast  Guard  to  implement  EDI  for  commercial 
purchases. 


Streamlined  Automated  Logistics  Transmission  System 

The  Navy  developed  the  SALTS  in  February  1991  during  Operation  Desert 
Storm  to  allow  Navy  and  Marine  Corps  supply  officers  to  transmit  logistical 
information.  SALTS  provides  an  alternative  to  tactical  networks  for  passing 
logistical  and  administrative  information. 

The  SALTS  is  a  IBM-compatible,  personal-computer  (PC)  MS-DOS-based 
communications  system  that  sends  requisitions  and  other  administrative  infor¬ 
mation  over  commercial  satellite  and  telephone  communications  networks.  Us¬ 
ing  an  IBM-compatible  PC,  SALTS  software,  a  modem,  and  telephone  or 
communications  link  to  the  International  Maritime  Satellite,  a  SALTS  user  trans¬ 
mits  administrative  messages  to  the  SALTS  central  computer  at  the  Navy 
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Figure  3-4. 

Direct  Transmission  to  DAAS  -  Data  Flow 


Aviation  Supply  Office  in  Philadelphia.  The  central  computer  receives  the  trans¬ 
mission  and  routes  it  to  its  final  destination.  In  addition  to  requisitions,  SALTS  is 
also  used  to  transmit  financial  and  personnel  transactions  as  well  as  electronic 
mail  messages  to  other  SALTS  users. 

Transaction  routing  by  the  SALTS  central  computer  is  completely  automatic. 
It  is  solely  a  "routing  hub."  As  does  the  Postal  Service,  it  reads  the  address  on 
the  incoming  transactions  from  SALTS  users  and  delivers  them  to  the  addressee. 
SALTS  central  computer  creates  an  electronic  post  office  box  to  hold  transactions 
for  SALTS  users.  Those  transactions  sit  in  the  electronic  post  office  awaiting 
retrieval  by  users  during  their  next  transmissions. 

The  flexibility  that  SALTS  provides  satisfies  the  communications  require¬ 
ments  of  MMS.  It  is  always  available;  it  is  accessible  from  remote  locations  using 
commonly  available  technology;  and  it  provides  many  users  with  access  to  the 
requisitioning  system  through  a  single  system.  The  USCGC  Jarvis  (WHEC  725) 
has  had  SALTS  capability  since  October  1992  when  the  Navy  provided  the  hard¬ 
ware,  software,  and  training  necessary  for  its  use.  The  experience  of  the  USCGC 
Jarvis  has  been  positive.  SALTS  is  used  both  in  port  and  underway  to  transmit 
requisitions,  receive  requisition  status,  and  send  messages  to  other  SALTS  users. 
Figure  3-5  shows  the  MMS  transaction  flow  using  SALTS  as  a  communications 
gateway. 
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Advantages 


Umttations 


Figure  3-5. 

Materiel  Management  System  Transaction  Flow  Using  SALTS 


The  following  are  the  advantages  of  SALTS  or  a  system  similar  to  SALTS: 

♦  Satisfies  MMS  requirement  for  a  gateway  that  all  users  can  access 

♦  Transmits  a  wide  range  of  administrative  data  between  units  at  sea  and 
shore  activities 

♦  Enhances  interoperability  with  the  Navy  and  all  of  DoD 

♦  Permits  nontactical  communication  with  other  SALTS  users 

♦  Has  the  potential  to  provide  interoperability  with  other  nations'  navies  and 
coast  guard  forces  for  joint  operations. 


As  mentioned  earlier  in  this  subsection,  SALTS  requires  an  IBM-compatible 
MS-DOS  operating  environment.  It  is  not  compatible  with  the  operating  system 
used  on  the  Coast  Guard  standard  workstation.  To  run  SALTS,  the  Coast  Guard 
must  either  modify  its  standard  workstations  to  run  IEM-compatible  MS-DOS  or 
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acquire  IBM-compatible  PCs  for  the  SALTS  workstation  or  port  SALTS  (which  is 
written  in  ANSI  Q  to  the  UNISYS  environment. 


Conclusions 


Given  the  goal  of  MMS  to  be  the  sole  Coast  Guard  requisitioning  system,  all 
units  must  be  able  to  use  MMS  to  send  requisitions  and  commercial  procurement 
information.  This  requires  a  communications  system  that  accommodates  all 
MMS  users.  The  operational  environment  of  a  class  01  users  (afloat  units) 
requires  a  communication  system  that  does  not  depend  solely  on  telephone  land¬ 
line  communications . 

Both  SALTS  and  a  SALTS-like  system  can  perform  the  function  of  a  commu¬ 
nications  gateway  for  MMS.  Such  a  gateway  has  the  potential  to  be  accessed  by 
all  Coast  Guard  units,  ashore  and  at  sea.  It  can  route  both  requisitions  and  com¬ 
mercial  purchase  transactions  through  MMS. 


Recommendations 

We  recommend  that  G-ELM  establish  a  communications  gateway  that  can  accom¬ 
modate  both  requisition  and  commercial  purchase  transactions.  We  further  recommend 
that  to  meet  such  a  requirement  the  Coast  Guard  establish  SALTS  or  a  system  similar  to 
SALTS  so  that  all  Coast  Guard  units  can  use  MMS.  The  communications  gateway 
must  accept  both  requisitions  and  commercial  purchase  information  from  units, 
it  must  ensure  that  the  requisitions  are  passed  on  to  DAAS  and  the  FINCEN,  and 
it  must  capture  both  requisition  and  commercial  purchase  data. 


Materiel  Management  System  Central 

The  MMS  Centred  is  an  organizational  entity  conceived  by  the  Electronics 
Engineering  Center  (EECEN)  business  area  analysis  (BAA)  described  in 
Chapter  1.  The  EECEN  BAA  described  an  MMS  Central  through  which  all  Coast 
Guard  requisition-related  transaction  among  and  between  the  unit,  DAAS,  and 
FINCEN  would  pass.  In  addition  to  routing  transactions,  MMS  Central  is  a  cen¬ 
tral  collection  point  for  all  Coast  Guard  requisition  data. 

Our  analysis  of  the  business  practices  for  MMS  leads  us  to  conclude  that  the 
establishment  of  an  MMS  Central  is  not  necessary.  While  we  have  concluded  that 
MMS  must  perform  the  functions  that  EECEN  assigns  to  MMS  Central,  we 
believe  that  it  is  unnecessary  to  perform  them  at  one  site.  While  the  concept  of  an 
MMS  Central  is  consistent  with  our  descriptions  of  MMS  business  practices,  it 
must  be  justified  by  a  cost  analysis. 
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Interim  Process  Improvements 


As  we  discussed  earlier  in  this  report,  many  units  circumvent  ARMS  requi¬ 
sition  processing  by  sending  requisitions  directly  to  DAAS  and  thus  bypassing 
the  financial  data  edit-check  and  obligation  reporting  procedures  established  in 
ARMS.  Although  units  that  send  requisitions  directly  to  DAAS  are  required  to 
establish  an  obligation  by  sending  DAAS  a  DIC  ZOA  transaction  that  mirrors  the 
requisition  to  ARMS,  many  obligations  are  not  established  because  either  the 
DIC  ZOA  is  not  sent  or  its  financial  information  is  incorrect  For  many  of  those 
requisitions,  a  financial  obligation  is  not  created  until  a  bill  is  received  from  tire 
source  of  supply. 

The  requirement  that  the  requisitioning  unit  send  a  DIC  ZOA  transaction  to 
ARMS  can  be  eliminated  by  requiring  DAAS  to  send  ARMS  a  copy  of  all  requisi¬ 
tions  it  receives  from  any  non-ARMS  Coast  Guard  requisitioner.  ARMS  would 
receive  those  transactions,  check  their  financial  data,  and  create  a  DAFIS  transac¬ 
tion  to  establish  an  obligation. 

Instead  of  sending  requisitions  directly  to  DAAS,  those  units  with  SALTS 
can  send  their  transactions  to  ARMS.  Those  requisitions  would  be  processed  in 
die  same  way  as  any  other  ARMS  requisition.  The  financial  data  edit  check 
would  validate  the  financial  information  and  create  and  obligation.  ARMS  will 
send  an  error  message  to  the  requsitioner  for  those  requisitions  with  invalid 
financial  data. 


Conclusion 


We  believe  that  requiring  DAAS  to  send  ARMS  a  copy  of  all  non-ARMS 
requisitions  received  from  Coast  Guard  requisitioners  will  improve  the  current 
requisitioning  system.  This  improvement  will  do  the  following: 

♦  Provide  ARMS  with  a  copy  of  all  requisitions  so  that  it  can  create  an  obliga¬ 
tion  before  a  bill  is  received  from  the  source  of  supply 

♦  Eliminate  the  need  for  the  unit  to  send  a  DIC  ZOA  transaction  for  each  mes¬ 
sage  or  DAMES  requisition. 

Although  ARMS  will  receive  a  copy  of  all  Coast  Guard  requisitions,  we  can¬ 
not  be  certain  that  the  financial  information  on  all  requisitions  is  valid.  The  fi¬ 
nancial  data  on  requisitions  sent  directly  to  DAAS  will  not  be  validated  before 
the  requisition  is  sent  to  the  source  of  supply.  However,  availability  of  a  copy  of 
the  requisition  will  give  the  financial  system  an  earlier  opportunity  to  correct 
any  errors. 
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Recommendations 


We  recommend  that  G-ELM  route  all  SALTS  requisitions  through  ARMS  and 
instruct  DAAS  to  route  a  copy  of  all  Coast  Guard  messages  and  Defense  Automated 
Message  Exchange  System  requisitions  through  ARMS  until  a  communications  gate¬ 
way  is  established.  The  TCC  Amdahl  computer  will  process  all  SALTS  requisitions 
through  ARMS  before  forwarding  them  to  the  source  of  supply.  A  copy  of  all 
messages  and  DAMES  requisitions  will  be  sent  to  ARMS  at  the  same  time  the 
requisition  is  sent  to  die  source  of  supply. 


Implementation  of  the  Defense  Logistics 
Management  System 

The  Coast  Guard  is  committed  to  utilizing  DoD  procedures  in  order  to  oper¬ 
ate  as  a  part  of  the  Department  of  the  Navy  in  wartime  and  other  national  emer¬ 
gencies.  However  the  decision  die  Coast  Guard  must  make  is  if,  when,  and  how 
to  implement  DLMS  within  MMS  prior  to  a  mandated  DoD-wide  implementa¬ 
tion  of  die  DLMS.  This  includes  whether  to  incorporate  it  as  a  part  of  the  initial 
MMS  development  or  to  develop  MMS  utilizing  the  DLSS  and  then  to  retrofit 
the  DLMS  into  it  when  DoD  implements  DLMS.  The  following  subsections  iden¬ 
tify  the  issues  associated  with  this  decision. 

Benefits  of  Implementing  the  Defense  Logistics  Management  System 

Enhanced  data  capability  is  the  key  feature  of  the  DLMS.  The  EDI,  variable- 
length  transactions  permit  creation  of  new  data  fields  and  increasing  die  size  of 
existing  fields.  As  noted  earlier,  more  than  100  enhancements  have  already  been 
incorporated  into  DLMS  Version  2.0  and  more  will  be  included  over  time.  Most 
of  the  enhancements  are  in  MILSTRIP,  which  MMS  will  utilize.  Among  the  more 
important  enhancements  are  the  following: 

♦  Requisitions  for  different  items  contained  in  one  DLMS  transaction  set 

♦  Exception  data,  including  both  fielded  and  text  data 

♦  Serial,  lot,  or  batch  number  identification 

♦  Multiple  advice  codes 

♦  Supply-assistance  message 

♦  Coast  Guard-unique  codes  and  data 

♦  Requisition  quantities  by  weapons  systems  and  reason  for  requisitioning 


3-24 


♦  Specification  of  any  combination  of  earliest  acceptable,  latest  acceptable,  and 
required  delivery  dates 

♦  Multiple  status  addresses  (requisitioner,  bill-to,  ship-to,  and  others  as 
needed) 

♦  In-the-clear  addressing 

♦  Marks  and  numbers 

♦  Long-line  accounting  data. 

The  DLMS  and  EDI  provide  the  opportunity  to  move  the  Coast  Guard  from 
proprietary  electronic  exchanges  internally  and  paper  in  its  exchanges  with  in¬ 
dustry  to  an  integrated  ASC  X12  EDI  process.  EDI  can  serve  as  the  single  format 
to  support  all  of  Coast  Guard  logistics  transactions:  within  the  Coast  Guard, 
inter-Service,  intra-agency,  and  between  the  Coast  Guard  and  industry. 

The  primary  reason  for  the  Coast  Guard  to  incorporate  DLMS  into  MMS  is 
the  data-modeling  effort  that  it  is  currently  pursuing.  If  new  Coast  Guard  sys¬ 
tems  will  use  only  the  data  elements  used  by  the  DLSS,  the  Coast  Guard  has  lit¬ 
tle  reason  to  make  the  transition  to  DLMS.  However,  if  functional  process 
improvements  require  additional  data  exchanges,  only  the  DLMS  can  meet 
those  requirements.  Because  future  logistics  operations  concepts  will  probably 
include  far  more  data  exchanges  than  currently  occur,  the  Coast  Guard  should 
move  towards  DLMS  implementation.  For  the  near  term,  the  Coast  Guard 
should  maintain  the  flexibility  to  continue  to  transmit  in  the  DLSS  with  those 
recipients  who  are  not  DLMS  capable. 


Enhanced  Data 

One  of  the  most  valuable  aspects  of  the  DLMS  is  that  its  transaction  sets  are 
not  limited  to  80  characters.  DLMS  Version  2.0  contains  many  new  data  ele¬ 
ments,  and  additional  enhancements  will  be  added  over  time.  However,  these 
enhanced  data  can  be  readily  communicated  only  when  both  the  sending  and  re¬ 
ceiving  activities  are  DLMS-capable.  Enhanced  data  will  be  lost  in  any  down¬ 
ward  translation  back  to  DLSS  format  so  it  must  be  communicated  in  another 
media.14 

For  example,  if  a  depot  ships  firearms  to  a  retail  site  using  the  DLMS  85615 
transaction  set,  the  serial  numbers  of  all  the  weapons  being  shipped  would  be 
included.  However,  if  the  receiving  site  were  only  DLSS  capable,  then  DAAS 
would  be  unable  to  forward  Transaction  Set  856.  DAAS  would  convert  it  into  a 
DLSS  DIC  AS1  (shipment-status-to- requisitioner  transaction)  and  the  serial 


“Activities  can  work  with  other  transaction  senders  and  receivers  to  determine  and 
develop  means  by  which  non-DLMS  sites  can  obtain  the  enhanced  data  electronically; 
for  example,  through  DLSS  trailer  cards. 

15  Ship  Notice/Manifest  transaction  set  used  to  transmit  shipping  information. 
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number  data  would  be  lost  to  the  receiving  site.  The  transmitting  site  would 
have  to  provide  the  enhanced  data  in  paper  or  other  format. 


O  USON 


Assuming  that  the  Coast  Guard  will  include  additional  data  elements  in 
both  MMS  and  modernization  of  the  supply  centers,  the  timing  of  the  imple¬ 
mentation  of  the  two  systems  may  affect  how  the  DLMS  are  implemented.  If  the 
supply  centers  and  units  incorporate  the  new  data  elements  and  DLMS  at  ap¬ 
proximately  the  same  time,  then  exchanging  enhanced  data  will  be  relatively 
easy  through  the  DLMS.  However,  if  MMS  is  implemented  with  enhanced  data 
and  DLMS  capability  significantly  earlier  titan  the  supply  centers,  some  means 
of  dealing  with  the  enhanced  data  must  be  provided.  The  following  approaches 
are  among  those  that  may  be  used: 

♦  Incorporate  into  the  MMS  switch  (DLSS  path)  the  capability  to  create  trailer 
images  for  the  enhanced  data.  ( Note:  The  supply  center  software  will  have 
to  be  modified  to  receive  and  print  the  trailer  images.) 

♦  Transmit  in  the  DLSS  and  handle  enhanced  data  manually  by  message, 
telephone,  letter,  etc. 

♦  Design  MMS  for  enhanced  data  but  do  not  implement  it  until  the  supply 
centers  are  capable  of  receiving  it 

RfiGOMMENDAHON 

We  recommend  that  G-ELM  review  DLMS  enhancements  and  determine  what 
enhanced  data  capabilities  apply  to  Coast  Guard  logistics  transactions.  In  reviewing 
this  capability,  G-ELM  should  consider  the  requisition-  and  shipping-related 
data  that  are  currently  exchanged  between  Coast  Guard  units  and  supply  cen¬ 
ters  in  manual  formats.  It  then  should  identify  the  desired  requisition-  and 
shipping-related  data  that  will  be  transmitted  in  MMS  in  light  of  the  enhanced 
data  capabilities  of  DLMS.  The  Coast  Guard  supply  centers  should  be  provided 
the  capability  to  receive  DLMS  Version  2.0  transactions  at  the  same  time  other 
Coast  Guard  units  implement  MMS,  assuming  MMS  is  designed  to  transmit  en¬ 
hanced  data. 

Risks  and  Uncertainties  in  Implementing  the  Defense  Logistics 
Management  System 

Technical  Risk 

The  DLMS  is  the  DoD  utilization  of  EDI  for  internal  logistics  communica¬ 
tions.  EDI  has  been  widely  used  in  private  industry  for  years  and  its  use  within 
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the  Federal  Government  is  increasing.  Hence,  implementation  of  the  DLMS  rep¬ 
resents  little  or  no  technical  risk. 


Implementation  Risk 

Considerable  uncertainty  exists  about  DoD's  schedule  for  implementing 
the  DLMS  on  a  Do D- wide  basis.  A  March  1992  memorandum  of  understanding 
among  the  Office  of  the  Secretary  of  Defense,  the  Joint  Logistics  Systems  Center, 
Defense  Distribution  Systems  Center,  and  DLMSO  states  the  DLMS  ASC  X12 
EDI  transaction  sets  will  be  the  basis  for  communication  among  Corporate 
Information  Management  (CIM)  systems.  CIM  system  fielding  will  be  the  pri¬ 
mary  path  to  DLMS  implementation.  However,  the  timing  for  fielding  CIM  sys¬ 
tems  at  ICPs  and  depots  is  currently  unclear,  and  clarification  is  likely  to  take 
several  years.  Whether  a  CIM  standard  system  for  retail  sites  will  be  developed 
or  whether  the  Services  will  continue  to  operate  individual  systems  is  also  un¬ 
clear  as  is  the  timing  for  incorporating  DLMS  within  die  CIM  systems.  Further¬ 
more,  no  decision  has  yet  been  made  as  to  whether  DLMS  will  be  a  part  of  die 
initial  fielding  or  will  not  be  incorporated  until  after  initial  fielding  is  completed. 


Migration  Strategy 

One  approach  that  would  minimize  the  risks  while  developing  an  early 
DLMS  capability  would  be  to  incorporate  both  DLMS  and  DLSS  formats  in  die 
MMS  transaction-generation/  receiving  modules.  The  format  that  is  to  be  used 
can  be  controlled  by  a  software  switch  that  can  be  set  up  in  one  of  two  ways: 

♦  All  or  nothing.  This  switch  would  be  initially  set  for  the  DLSS  formats  and 
would  remain  that  way  until  all  DoD  and  Coast  Guard  sites  move  to  DLMS; 
at  that  time,  it  would  be  switched  to  DLMS  and  would  remain  there. 

♦  Selective  (or  parallel).  This  switch  would  select  between  DLSS/ DLMS  formats 
for  each  transaction  generated. 

The  selective  switch  would  be  associated  with  a  table  of  Department  of 
Defense  Activity  Address  Codes  (DoDAACs)  containing  an  indicator  as  to 
whether  die  recipient  is  DLSS-  or  DLMS<apable.  MMS  programs  would  format 
die  transaction  based  on  the  table  entry  (see  Figure  3-6).  MMS  would  also  have 
to  be  able  to  receive  transaction  data  in  either  format.  That  can  readily  be  accom¬ 
modated  based  on  the  telecommunications  source.  In-bound  DLSS  traffic  will 
continue  to  come  through  the  AUTODIN,  which  has  supported  DLSS  traffic 
since  1965.  Inbound  DLMS  traffic  will  come  through  the  Defense  Integrated  Sys¬ 
tems  Network  (DISN)  (see  Figure  3-6). 
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Figure  3-6. 

Flow  ofMMS  Data  to  DLSS/DLMS  Formats 


Conclusion 

The  selective  approach  would  permit  Coast  Guard  sites  to  gain  DLMS  capa¬ 
bility  without  losing  the  ability  to  exchange  data  with  activities  that  continue  to 
use  DLSS  formats.  Coast  Guard  sites  can  implement  DLMS  selectively  with  a 
willing  trading  partners)  either  within  the  Coast  Guard  or  with  another  agency. 
DAASC  is  also  planning  to  be  able  to  convert  transactions  between  DLMS  and 
DLSS  as  needed. 


Recommendation 

We  recommend  that  the  Coast  Guard  design  for  M MS  provide  the  capability  for 
automatically  selecting  either  DLSS  or  DLMS  transaction  formats.  The  selective 
switch  (described  in  Figure  3-6)  will  be  able  to  produce  transactions  in  either 
DLSS  or  DLMS  formats  depending  on  the  capabilities  of  the  recipient 
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Chapter  4 

Recommended  Materiel  Management 
System 


Interim  Requisitioning  Process  Improvements 

In  Chapter  3,  we  recommend  that  G-ELM  route  all  SALTS  requisitions 
through  ARMS  and  instruct  DAAS  to  route  a  copy  of  all  Coast  Guard  requisi¬ 
tions  it  receives  directly  from  Coast  Guard  units  to  ARMS.  That  will  enable  the 
Coast  Guard  to  process  all  SALTS  requisitions  through  the  ARMS  edit  checks, 
and  create  a  financial  obligation  before  it  is  passed  to  the  source  of  supply.  It  will 
enable  ARMS  to  create  an  obligation  for  all  message  and  DAMES  requisitions 
with  valid  financial  information  at  the  time  the  requisition  is  passed  to  the 
source  of  supply.  Requisitions  with  invalid  financial  information  must  be  manu¬ 
ally  researched  to  establish  an  obligation.  Figure  4-1  shows  the  interim  Coast 
Guard  requisitioning  process  using  ARMS  after  this  recommendation  is  imple¬ 
mented. 


are  in  DLSS  format. 


Figure  4-1. 

Interim  Flow  of  Coast  Guard  Requisition  Information 


The  interim  requisitioning  system  will  allow  the  Coast  Guard  to  process  all 
requisitions  through  ARMS.  Requisitioners  will  continue  to  send  requisitions 


using  current  methods.  ARMS  requisitioning  units  will  send  requisitions  to  the 
TCC  Amdahl  computer,  SALTS  users  will  send  requisitions  to  ARMS  via 
SALTS,  and  DAMES  and  message  requisitioned  will  continue  to  send  their  req¬ 
uisitions  directly  to  DAAS.  When  DAAS  receives  unedited  requisitions  from  any 
Coast  Guard  source  other  than  ARMS,  it  will  forward  a  copy  of  the  requisition 
to  the  TCC  Amdahl  computer  for  processing  through  ARMS.  ARMS  will  process 
those  requisitions  through  its  edit  checks  and  send  a  DAFIS  transaction  to  the 
DAFIS  computer  center  to  create  an  obligation.  DAAS  will  forward  all  requisi¬ 
tions  received  from  ARMS  to  the  source  of  supply.  It  will  route  a  copy  of  all 
status  to  ARMS  and  to  the  requisitioner  in  the  manner  (message,  DAMES, 
SALTS,  or  ARMS)  indicated  in  the  media  and  status  on  the  original  requisition. 


Materiel  Management  System  Processes 

Our  description  of  how  we  believe  the  MMS  should  function  is  divided  into 
the  requisitioning  process,  commercial  procurement  process,  and  data -collection 
process. 


Requisitioning  Process 

The  requisitioning  process  starts  after  a  materiel  need  is  identified  and  Gov¬ 
ernment  (Coast  Guard  or  other  Government  agency)  source  of  supply  has  been 
identified.  Figure  4-2  shows  the  path  of  the  requisition  and  requisition-related 
information. 


Figure  4-2. 

Recommended  MMS  Transactions  -  Data  Flow 
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Sending  a  Requisition 


Defense  Logistics  Standard  System  Environment 

The  MMS  creates  the  requisition  at  the  unit  level  on  the  Coast  Guard  stan¬ 
dard  workstation.  The  application  software  can  create  a  complete  and  correct 
DLSS  requisition.  The  software  ensures  that  all  required  data  fields  are  com¬ 
pleted  and  that  Coast  Guard-specific  data  such  as  financial  obligation  informa¬ 
tion  are  valid.  MMS  creates  a  second  80-character  image  that  contains  the 
additional  data1  necessary  to  create  a  financial  obligation.  MMS  sends  the  edited 
DLSS  requisition  and  second  80-character  image  to  the  communications  gateway 
in  DLSS  format. 

The  communications  gateway  receives  the  DLSS  requisition  and  automati¬ 
cally  routes  a  copy  of  the  first  80-character  requisition  image  to  DAAS,  and  the 
CGLIF.  The  communications  gateway  sends  both  the  original  requisition  and 
the  second  80-character  image  to  the  DAFIS  translator. 

The  DAFIS  translator  creates  a  DAFIS-formatted  obligation  transaction  from 
the  DLSS  requisition  and  second  80-character  image  and  maintains  a  record  link¬ 
ing  the  requisition  number  to  a  line  of  accounting  data.  The  translator  passes  a 
DAFIS-formatted  transaction  to  the  DAFIS  computer  center  to  create  an  obliga¬ 
tion. 


DAAS  receives  the  requisition  and  passes  it  to  the  source  of  supply. 
The  CGLIF  receives  the  requisition  and  creates  a  tracking  record. 


Defense  Logistics  Management  Systems  Environment 

All  MMS  sites  will  use  the  general  approach  shown  in  Figure  4-3  to  process 
DLMS  transactions.  MMS  programs  would  extract  requisition  data  from  MMS 
files,  and  the  extraction  program  will  edit  the  data  to  ensure  that  it  meets  all 
Coast  Guard  and  DLMS  edit  criteria,  including  die  following  ones: 

♦  All  DLMS  and  Coast  Guard-required  fields  are  present 

♦  A  "TO"  address  with  a  valid  DoDAAC  (OPFAQ  is  present. 

♦  All  codes  used  are  valid. 

♦  Valid  financial  information  is  provided,  including  fund  code,  program  ele¬ 
ment,  cost  center,  appropriation  limitation  code,  region  code,  and  system 
data. 


’The  80-character  image  contains  the  program  element,  cost  center,  appropriation 
limitation  code,  region  code,  and  system  data. 
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Figure  4-3. 

General  Flow  of  DIMS  Transactions 


The  output  of  the  extraction  program,  typically  called  a  flat  file,2  is  given  to 
the  EDI  translator  for  conversion  to  DLMS  format  The  translator,  after  creating 
the  EDI  format,  packages  the  transactions  into  functional  groups  and  creates  an 
interchange  envelope.3  The  data  are  compressed,  archived,4  and  transmitted  to  a 
communications  gateway.  The  communications  gateway  sends  the  requisition  to 
DAAS,  tiie  DAFIS  translator,  and  the  CGLIF. 

The  MMS  sites  will  have  procedures  for  collecting  and  resolving  errors 
detected  by  local  software  or  by  other  trading  partners.  Errors  detected  by  trad¬ 
ing  partners  will  be  identified  to  the  initiating  MMS  sites  through  EDI  transac¬ 
tions.  Three  different  transactions  will  be  used: 

♦  Transaction  Set  TA1  —  Interchange  Acknowledgment 


2  Flat  file  in  EDI  terminology  is  a  stream  of  transaction  data  flowing  between  the 
application  data  base  (MMS)  and  the  EDI  translator.  The  data  stream  is  usually  a  simple 
sequential  file  where  precise  format  depends  on  the  specific  EDI  translator  and  applica¬ 
tion  data  base  being  used. 

*  Multiple  requisitions  can  be  incorporated  into  a  DLMS  511  transaction  set  In  turn, 
multiple  511  transaction  sets  can  be  bundled  together  into  a  functional  group.  Multiple 
functional  groups  can  be  bundled  into  an  interchange  set  (envelope)  for  transmission. 

4  Archiving  consists  of  retaining  a  copy  of  a  transmission  to  guard  against  its  being 
lost  or  inadvertently  destroyed  during  telecommunication  or  by  the  receiving  party.  If 
tiie  original  is  lost  or  destroyed,  the  archived  copy  should  be  readily  retrievable  and  can 
be  transmitted.  For  these  purposes,  archived  materiel  needs  to  be  kept  for  only  a  rela¬ 
tively  short  time  (DAASC  will  maintain  archives  for  an  extended  period  of  time).  For 
commercial  procurements  and  other  sensitive  data  transmissions,  archives  may  need  to 
be  maintained  for  auditing. 
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♦  Transaction  Set  997  —  Functional  Acknowledgment 

♦  Transaction  Set  824  -  Application  Advice. 

The  DAAS  acts  as  the  hub  for  all  DLMS  transactions.  It  archives,  edits, 
routes,  and  distributes  transactions.  It  also  acts  as  a  gateway  for  connecting  DoD 
activities  to  commercial  trading  partners  for  DLMS  and  other  EDI  transactions. 

The  DAAS  receives  the  envelopes  (see  Figure  4-4),  evaluates  the  interchange 
content  to  determine  those  transaction  sets  that  require  further  editing,  passes 
those  transactions  through  their  translator,  and  processes  the  transactions. 

♦  The  DAAS  archives  all  incoming  envelopes  for  a  period  of  at  least  30  days. 

♦  The  data  are  decompressed. 

♦  The  DAAS  translator  initiates  a  Transaction  SetTAl  back  to  the  sending 
translator  acknowledging  receipt  of,  or  inability  to,  open  the  interchange 
envelope. 

♦  If  the  DAAS  translator  is  unable  to  process  any  transaction  set(s)  within  the 
envelope  because  of  EDI  syntax  errors,  a  Transaction  Set  997  will  be  sent  to 
the  originator  identifying  the  specific  transaction  sets  that  cannot  be  proc¬ 
essed. 


Figure  4-4. 

DLMS  Transaction  Flow  -  DAAS  Processing 


4-5 


The  translator  then  passes  to  DAAS  application  programs  a  flat  file  of  the 
transaction  set  that  were  enclosed  in  the  envelope. 

The  DAAS  will  use  application  software  to  open  transaction  sets  down  to 
the  transaction  (individual  requisition  level)  and  will  perform  the  following 
functions  on  transactions: 

♦  Basic  edits.  Transaction  Set  824  provides  functional  advice,  including  trans¬ 
action  rejects.  For  the  following  reasons,  a  Transaction  Set  824  may  be  sent 
back  to  the  originator: 

►  Requisition  quantity  is  zero 

►  No  valid  hind  code 

►  No  stock  or  part  number. 

♦  Validation  of  the  national  stock  number  against  the  managing  activity  and 
rerouting  if  needed. 

♦  Generation  of  images,  as  needed. 

♦  Holding,  forwarding,  or  modifying  returning  status  per  Coast  Guard  profile 
for  the  MMS  site. 

♦  Executing  "suppress"  or  other  national  command  directives. 

♦  Loading  transaction  data  into  LIPS. 

The  DAAS  sorts  all  requisition-related  transactions  in  a  given  processing 
window  or  queue  by  type  and  "TO"  address.  It  then  generates  new  transaction 
sets  and  functional  groups,  and  die  outbound  translator  converts  them  as 
required  into  EDI  format,  compresses  the  data,  archives  die  outbound  messages, 
and  transmits  them  to  recipients. 

The  DAFIS  translator  creates  a  DAFIS-formatted  obligation  transaction  from 
the  requisition.  It  passes  the  DAFIS  obligation  transaction  to  die  DAFIS  com¬ 
puter  center. 

The  CGLIF  receives  die  requisition  and  creates  a  tracking  record. 

The  receiving  activity's  translator  receives  and  performs  EDI  syntactical 
analysis  on  incoming  envelopes  and  enclosed  transaction  sets  (see  Figure  4-5). 

♦  It  issues  a  Transaction  Set  TA1  either  accepting  or  rejecting  each  envelope 
received. 


4-6 


♦  It  issues  a  Transaction  Set  997  for  each  transaction  set  that  fails  syntactical 
edits. 


Figure  4-5. 

DLMS  Transaction  Flow  -  Recipient  Processing 


The  translator  converts  the  data  from  EDI  format  to  a  flat-file  format.  That 
process  entails  breaking  envelopes/  functional  groups  to  the  transaction  set  level 
and  routing  transactions  sets  to  the  requisition-processing  software. 

The  receiving  application  software  applies  the  required  edits  and  should 
make  every  effort  to  process  the  requisition.  When  it  cannot  do  so,  it  rejects  the 
transaction  and  submits  a  Transaction  Set  824.  When  a  transaction  contains 
errors,  but  is  still  processable,  advisory  errors  can  be  sent  to  the  originator 
through  the  DAAS  on  a  Transaction  Set  824. 

In  the  rare  case  that  DAAS  incorrectly  routes  a  requisition,  the  receiving 
activity  re-routes  it  to  the  correct  recipient  when  that  recipient  is  known  (e.g.,  for 
items  assigned  to  a  new  activity).  DAAS  and  the  originator  is  notified  by  a 
Transaction  Set  824. 

For  a  requisition,  none  of  the  TA1,  997,  or  824  transaction  sets  convey  sup¬ 
ply  status.  Transaction  Sets  997  and  824  are  used  only  to  report  error  conditions. 
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Prochsing  Requisitioning  Status 
Defense  Logistics  Standard  System  Environment 


Requisition  status  transactions  are  created  and  transmitted  by  the  source  of 
supply  to  communicate  changes  in  the  status  of  a  requisition  or  are  submitted  in 
response  to  an  inquiry  from  the  requisitioning  unit.  Status  transactions  start 
when  the  source  of  the  supply  sends  a  standard  DLSS  status  transaction  to 
DAAS.  The  DAAS  routes  all  status  transactions  to  the  communications  gateway 
for  distribution  to  the  requisitioning  unit  and  the  CGLIF.  Additionally,  those 
status  transactions  (identified  by  their  document  identifier  code)  that  affect  the 
financial  obligation  are  addressed  to  the  DAFIS  translator  at  the  F1NCEN. 

The  CGLIF  receives  the  status  transaction  and  adds  it  to  the  tracking  record 
established  when  tire  requisition  was  created.  The  DAFIS  translator  matches  the 
requisition  number  on  the  status  transaction  to  a  line  of  accounting  data,  and 
creates  a  DAFIS-formatted  transaction  and  transmits  it  to  the  DAFIS  computer 
center  to  modify  the  obligation. 


Defense  Logistics  Management  Systems  Environment 

The  DLMS  processing  rules  are  the  same  for  supply  status  as  for  requisition 
processing.  All  supply  and  shipment  status  is  returned  to  the  originator  through 
DAAS.  Where  the  original  requisition  requests  multiple  status  addressees,  the 
receiving  activity  will  supply  one  status  transaction  to  DAAS,  and  it  will  per¬ 
form  the  distribution.  Supply  status  is  generated  by  die  application  system  and 
reported  on  Transaction  Set  870,  Order  Status  Report.  Since  Transaction  Set  870 
contains  the  same  financial  data  as  the  requisition,  the  DAFIS  translator  does  not 
maintain  a  record  linking  the  line  of  accounting  data  to  die  original  transaction. 


Staging  Information 

When  a  requisitioned  item  is  received  by  an  intermediate  Coast  Guard  stor¬ 
age  activity  or  any  activity  that  is  temporarily  holding  materiel  for  die  end  user, 
die  activity  enters  staging  information  in  die  CGLIF.  The  staging  activity  trans¬ 
mits  a  transaction  to  die  communications  gateway,  addressed  to  the  CGLIF,  to 
update  the  requisition's  tracking  record. 


Commercial  Procurement  Process 

The  MMS  will  not  transmit  commercial  procurement  orders.  Unlike  the 
Federal  Supply  System's  requisitioning  process,  the  unit-level  commercial  pro¬ 
curement  process  is  not  governed  by  a  standard  set  of  rules  for  all  commercial 
vendors.  Each  vendor  has  a  unique  set  of  rules  and  requirements  when  an  order 
is  placed.  MMS  captures  data  from  the  commercial  procv  rement  process. 
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Entering  Commercial  Purchase  Information 


The  commercial  procurement  process  starts  after  a  purchase  order  is 
approved,  and  the  order  is  placed  with  a  commercial  vendor.  In  a  transaction 
separate  from  the  one  placing  the  commercial  purchase,  MMS  transmits 
(Figure  4-2)  information  relating  to  that  procurement  to  the  CGLIF  for  tracking 
and  data  collection.  MMS  is  linked  to  the  application  that  creates  the  commercial 
purchase  order,  facilitating  a  capability  to  automatically  receive  purchase  order 
information  and  create  a  standard  transaction  to  input  purchase  order  informa¬ 
tion  to  die  CGLIF  at  the  time  of  purchase  order  placement  The  document  num¬ 
ber,  short  description  of  the  item,  quantity,  price,  commercial  source  of  supply, 
and  estimated  delivery  date  are  examples  of  information  required  on  the  input 
transaction.  The  input  transaction  is  sent  to  the  communications  gateway 
addressed  to  the  CGLIF. 

Receiving  Commercial  Purchase  Status  Information 

Vendor  transactions  provide  status  of  commercial  purchases.  As  the  status 
is  received,  transactions  are  created  to  update  the  tracking  record.  The  status 
transaction  is  transmitted  to  the  CGLIF  via  the  communications  gateway.  The 
CGLIF  receives  the  status  and  adds  it  to  the  tracking  record. 

Staging  information  is  input  to  the  CGLIF  when  a  commercially  purchased 
item  is  received  by  an  intermediate  Coast  Guard  storage  activity.  The  staging 
activity  transmits  a  transaction  to  the  communications  gateway,  addressed  to 
the  CGLIF,  to  update  the  commercial  purchase's  tracking  record. 


Data-Collection  Process 

The  CGLIF  performs  the  data-collection  (described  in  Chapter  3)  function 
for  MMS.  All  requisition  and  commercial  procurement  transactions  passing 
through  die  communications  gateway  are  passed  to  the  CGLIF.  Figure  4-2 
shows  data  flows  to  the  CGLIF. 

The  communications  gateway  sends  the  following  data  to  the  CGLIF: 

♦  Requisitions  and  commercial  procurement  transactions  from  the  vuiits  initi¬ 
ating  the  transactions 

♦  All  DLSS  status  transactions  from  DAAS 

♦  Commercial  status  transactions  from  the  unit  initiating  the  commercial  pur¬ 
chase 

♦  Staging  information  from  intermediate  storage  activities. 

The  communications  gateway  provides  Coast  Guard  units  access  to  the 
CGLIF.  Standard  transactions  or  interactive  data  screens  allow  users  to  retrieve 
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necessary  data.  Additionally,  the  CGLIF  provides  requisitioning  and  commercial 
purchase  data  to  the  Parts  Tracking  System. 


Materiel  Management  System  Organizational  Entities 

This  section  describes  the  organizational  entities  that  make  up  our  recom¬ 
mended  MMS. 


Unit-Level  Materiel  Management  System 

At  the  unit  level,  MMS  creates,  edits,  and  transmits  requisitions  into  the 
Federal  Supply  System.  The  MMS  unit-level  application  creates  a  complete  DLSS 
requisition  in  either  DLSS  or  DLMS  format.  Edit  tables  exist  to  ensure  the 
validity  of  all  Coast  Guard-specific  data  on  die  requisition.  The  unit-level  MMS 
hardware  sends  the  requisition  into  the  supply  system  through  the  communica¬ 
tions  gateway. 

The  unit-level  MMS  application  extracts  information  from  a  commercial  pin- 
chase  order  and  transmits  it  to  the  CGLIF  (data-collection  system). 


Communications  Gateway 

The  MMS  communications  gateway  functions  similarly  to  the  Navy's  SALTS 
as  a  routing  hub  to  forward  transactions  to  their  ultimate  destination.  The  com¬ 
munications  gateway  is  accessible  by  either  telephone  landline  or  cellular  and 
satellite  transmissions. 


Coast  Guard  Finance  Center 

The  FINCEN's  MMS  software  converts  the  standard  requisitioning  data  plus 
the  program  element,  cost  center,  appropriation  limitation  code,  region  code,  and 
system  data  into  a  line  of  accounting  data.  The  FTNCEN  maintains  a  file,  by  req¬ 
uisition  number,  of  all  financial  obligation  accounting  data  sent  to  DAFIS. 


Departmental  Accounting  and  Financial  Information 
System  Translator 

The  DAFIS  translator  converts  the  financial  accounting  data  and  DLSS  requi¬ 
sition  into  a  320-character  DAFIS-formatted  transaction.  The  DAFIS  transaction 
is  sent  to  the  DAFIS  computer  center  to  either  generate,  modify,  or  expend  an 
obligation. 
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Coast  Guard  Logistics  Intelligence  File 

The  CGLIF  receives  requisitioning  and  commercial-purchasing  data  from 
die  communications  gateway.  It  maintains  and  provides  access  to  current  trans¬ 
action  information.  The  CGLIF  archives  historical  data  from  completed  transac¬ 
tions  for  data  query  and  analysis. 


Staging  Activities 

The  staging  activities  are  typically  the  shore  support  or  maintenance  activi¬ 
ties  that  temporarily  stores  materiel  between  the  source  of  supply  and  its  ulti¬ 
mate  destination.  Staging  activities  input  transactions  for  the  receipt  and 
disposition  of  in-transit  materiel  to  the  CGLIF. 


Defense  Automatic  Addressing  System 

The  DAAS  receives  requisitions  in  either  DLSS/DLMS  format  from  the 
communications  gateway  and  routes  them  to  the  source  of  supply.  It  receives 
status  transactions  from  the  source  of  supply  and  routes  them  to  the  communi¬ 
cations  gateway. 
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Glossary 


ADP 

AFC 

ANSI 

ARMS 

ASC 

ASCII 

AUTODIN 

BAA 

CALS 

CAR 

CASREP 

CGLIF 

OM 

DAAS 

DAASC 

DAFIS 

DAMES 

DIC 

DISA 

DLA 

DLMS 

DLMSO 


=  automated  data  processing 
=  allotment  fund  code 
=  American  National  Standards  Institute 
=  Automated  Requisition  Management  System 
=  Accredited  Standards  Committee 
=  American  Standard  Code  for  Information  Interchange 
=  Automated  Digital  Network 
=  business  area  analysis 

=  Computer-aided  Acquisition  and  Logistics  System 
=  Conceptual  Architecture  Report 
=  casualty  report 

=  Coast  Guard  logistics  intelligence  file 
=  Corporate  Information  Management 
=  Defense  Automatic  Addressing  System 
=  Defense  Automatic  Addressing  System  Center 
=  Departmental  Accounting  and  Financial  Information  System 
=  Defense  Automated  Message  Exchange  System 
=  document  identifier  code 

-  Defense  Information  Systems  Agency 
=  Defense  Logistics  Agency 

=  Defense  Logistics  Management  Systems 

-  Defense  Logistics  Management  Standards  Office 
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MILSCAP  =  Military  Standard  Contract  Administration  Procedures 

MILSTAMP  =  Military  Standard  Transportation  and  Movement  Procedures 

MILSTEP  =  Military  Supply  and  Transportation  Evaluation  Procedures 

MILSTRAP  =  Military  Standard  Transaction  Reporting  and  Accounting 
Procedures 

MILSTRIP  =  Military  Standard  Requisitioning  and  Issue  Procedures 

MLCA(v)  =  Vessel  Division  of  Maintenance  and  Logistics  Command 
Atlantic 

MMS  =  Materiel  Management  System 

MODELS  =  Modernization  of  the  Defense  Logistics  Standard  Systems 

OPFAC  =  operating  facility 

OSC  =  Operations  Systems  Center 

PC  =  personal  computer 

RJE  =  remote  job  entry 

ROD  =  Report  of  Discrepancy 

SAIL  =  Systems  to  Automate  and  Integrate  Logistics 

SALTS  =  Streamlined  Automated  Logistics  Transmission  System 

SDR  =  Supply  Discrepancy  Report 

TCC  =  Transportation  Computer  Carter 

USCG  =  US.  Coast  Guard 

USCGC  =  US.  Coast  Guard  Cutter 

VAN  r'  value-added  network 

VNTSC  =  Volpe  National  Transportation  System  Center 
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transmit  requisitions  from  all  Coast  Guard  units;  and  (4)  the  effect  of  Defense  Logistics  Management  Systems  (DLMS)  Version  2.0  on  the  implementation  of 
MMS. 

From  our  analysis  of  the  issues  and  requirements  of  MMS,  we  recommend  that  die  Coast  Guard  take  the  following  action:  perform  requisition-related  financial 
data  edit  checking  at  the  unit  level;  eliminate  the  operating  facility/fund  code  table;  develop  and  maintain  a  translator  to  convert  Defense  Logistics  Standard  System 
(DLSS)  transactions  into  Departmental  Accounting  and  Financial  Information  System-formatted  transactions;  establish  a  Coast  Guard  logistics  intelligence  file; 
design  the  data-collection  system  to  support  the  Parts  Tracking  System;  ensure  MMS  and  the  Parts  Tracking  System  do  not  duplicate  processes;  establish  a 
communications  gateway  that  can  accommodate  both  requisition  and  commercial  purchase  transactions;  instruct  Defense  Automatic  Addressing  System  to  route  a 
copy  of  all  Coast  Guard  message  and  Defense  Automated  Message  Exchange  System  requisitions  through  the  Transportation  Computer  Center  Amdahl  computer 
until  a  communications  gateway  is  established;  provide  the  capability  for  MMS  to  automatically  select  either  DLSS  or  DLMS  formats;  and  review  DLMS 
enhancements  and  determine  what  enhanced  data  capabilities  apply  to  Coast  Guard  logistics  transactions. 
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